Queue.dat
From FaHWiki
General
The 
queue.dat is used by the F@H client and the Cores it uses to process a Work Unit (WU), to store information on a particular WU and some information on the client itself. It is a binary file of a fixed size.
The content of the file can be viewed with Dick Howells qd (Queue Dump) tool.
There is an article available on this Wiki on how to use qd with some more information on it:
Howto use qd to debug the FAH client
As part of the qd documentation, a webpage was created which contains a hexadecimal dump of a queue.dat file, in which all the differently sized fields are made visible.
Format
The size starts with 4 bytes containing the version of the queue and another 4 bytes containing the current index. The current index is a value of 0-9 indicating which of the 10 entries in the queue is being used for the currently running WU.
Next are 10 indices of a fixed size containing the same kind of information of each WU.
Finally there 6 fields of 4 bytes containing the Performance Fraction (PF), the number of WUs the PF was calculated over, and the average Download and Upload Rate and the number of WUs they were calculated over.
At the very end of the queue.dat are 16 bytes of only zeros, which will probably be used in a future version of the queue.
The layout of a queue.dat file:
| The layout of each queue index:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Content Descriptions
The meaning of the values stored in the queue.dat file are not publicly documented. What is known of the meaning of each value was mostly figured out by Richard P. Howell IV, the author of the qd (Queue Dump) utility. He documented the output of his qd utility, thereby describing the meaning of each value in the queue.
Because he gave its own interpretation to each value, those values not always reflect 1-on-1 what the Folding@Home developers use that value for in the F@H client. An good example is the Status code stored in the queue.dat file. At first Dick Howell gave it own meaning to the values which he derived from the observed behavior of the F@H client. But when at a later point in time the F@H client was able to show those status codes it gave its own slightly different meaning of the value.
The descriptions of the values below are what Dick Howell gave them, most of the time those are independent of his qd utility but sometimes the description is put in the context of qd, the first publicly available queue.dat exploration tool.
Queue Version
The client stores its own queue revision level in queue.dat any time it creates a new queue.dat or updates an old one to a newer format. The format does not change every time a new client comes out, so the version number shown here may be perfectly up to date but still not show the latest client revision level. It would not be an error.
Current Index
When a work unit is downloaded, it is assigned to one of the ten queue entries. The data in queue.dat at that index is used by the client to keep track of that unit's status. It is especially needed if the client is stopped and restarted, or if finished work doesn't upload on the first attempt. This index number is also used in file names in the work subdirectory. In this example, since the current index is 7, the work file names have the string "_07" in them.
The indices are assigned sequentially, starting at 1, and cycling back to 0 after 9. If work is still active at the next sequential index (most likely because it has had a lot of trouble uploading), that index will be skipped over. An active index won't be reused unless there are no inactive ones left at all.
Status
The status printed by qd is an interpretation of an integer status code for each entry, sometimes influenced by other data fields in that entry, e.g. the Upload Status. The names given to these status codes by qd are a little different from the names printed by the client with its "-queueinfo" flag. If qd is started with the "-h" flag, it will print out an explanation of its status code names.
Status codes
Here is a list of all the possible status codes that can be printed for a queue entry. When qd was first written, the client had no publicly-available names, so qd made up names according to the status of the work unit, from the perspective of the user. The following list is available if qd is started with the "-h" flag:
The status code for each queue entry may be interpreted as follows:
(0) empty The queue entry has never been used, or has been completely cleared. (0) deleted The unit was explicitly deleted. (0) finished The unit has been uploaded. The queue entry is just history. (0) garbage The queue entry is available, but its history is unintelligible. (1) folding now The unit is in progress. Presumably the core is running. (1) queued for processing The unit has been downloaded but processing hasn't begun yet. (2) ready for upload The core has finished the unit, but it is still in the queue. (3) DANGER will be lost if client is restarted! Bug before V3b5, neglected to post status (1). (3) abandoned Bug before V3b5, neglected to post status (1), and client was restarted. (4) fetching from server Client presently contacting the server, or something failed in download. If this state persists past the current unit, the queue entry will be unusable, but otherwise things will go on as usual. (?) UNKNOWN STATUS = ?? Something other than 0 to 4.
The numbers in parentheses are the actual value used for that status code. Code (0) is called four different names depending on other data found in the queue entry.
Several months after all this was written and working as described, the guys at Stanford added the "-queueinfo" option to the client, and they gave their own names to these same codes according to the queue entry, from the perspective of the client, describing what it needs to do about it. Status code (3) really never happens any more, but here is what it calls the others.
(0) empty The queue index is available for reuse by a new unit. (1) active The unit files are actively processing, and the core should be running. (1) ready The unit files are ready for processing but are queued, and the core should be started to process them when earlier units are finished. (2) finished The core has finished the unit, and it needs to be uploaded. (4) fetching The index is allocated to a unit being fetched from a server.
The "fetching" status was not handled correctly until client version 5.0, which will free the index if it finds that status in the queue. If an earlier client was restarted and discovered the "fetching" status at one of the queue indices, it simply skipped over that index for ever afterward, never reclaiming it for further use.
It's unfortunate that the word finished is used with differing meanings. In the output from qd, "finished" means it's really all done, and the information still stored is just history. But if it's the client which says "finished", it means only that the processing has finished, and the work has not been sent back yet.
Padding
There isn't much known about this field. The qd source has a comment which says: "Pad for Windows, others as of v4.01". This probably means that these 4 bytes are filled with only zeros to pad the size of the file, so that the next bytes of non-zeros containing useful information start at the correct byte offset. Apparently only queue.dat files created by the F@H clients for Windows used this field for padding, where the Linux/FreeBSD/OpenBSD and Mac OS X clients started to behave like the Windows clients already did starting at v4.01 of the queue.dat.
Time Data
This field actually stores 2 values, the begin time and the end time.
The begin time is recorded by the client when it finishes downloading a new unit to process. It is an epoch 2000 value, based on the local machine's clock. If the clock is set accurately and the work unit is not a duplicate, the "begin" time will be only a few seconds after the "issue" time, the difference being simply the time it took to receive the unit over the Internet.
The end time is recorded by the client when the core returns with an indication that the processing has finished and the results file should be uploaded to the server. It is an epoch 2000 value, based on the local machine's clock, just like the "begin" time.
Server IP (until v3.0)
This is the IP address of the data server from which the work unit was downloaded. It is also the address to which the unit must eventually be uploaded if it is still active.
The Server IP for Folding@Home clients before v3.0 the value was stored at 040 bytes from the start of each queue index. Starting at byte 264 of each index is the Server IP for client v3.0 and later. The v3.0 and later clients also store the port number.
See also: Work Server
Upload Status
The Upload Status is not separately printed by qd, in stead it is used to determine the Status of the Work Unit.
If the Status is 0, indicating that the "queue index is available for reuse by a new unit", the Upload Status is used by qd to print "deleted" if the Upload Status is 0, or "finished" if the Upload Status is 1.
It's a flag indication if the WU has been uploaded or not.
Core URL
This full URL is actually constructed by qd (and the client) from the directory URL and the core number, both of which are stored in queue.dat. It can be used to verify that the server knows the correct client OS type, and also to determine which core is required for this work unit. At present, Core_65 is Tinker (Folding), Core_78 is Gromacs (Folding), Core_79 is double-precision SSE2 Gromacs (Folding), Core_82 is PMD Amber (Folding), Core_96 is QMD (Folding), and Core_ca used to be SPG (Genome). A newer core, Core_a0 is Gromacs 33 (Folding). See also: Cores
Misc1a
These numbers are present in queue.dat, but it isn't known for sure what they are. Most likely they are related to the revision levels of the client which are suitable for this work unit.
The other numbers are Misc1b and Misc3b
Core Number
This full URL is actually constructed by qd (and the client) from the directory URL and the core number, both of which are stored in queue.dat. It can be used to verify that the server knows the correct client OS type, and also to determine which core is required for this work unit. At present, Core_65 is Tinker (Folding), Core_78 is Gromacs (Folding), Core_79 is double-precision SSE2 Gromacs (Folding), Core_80 is SREM Gromacs (Folding), Core_82 is PMD Amber (Folding), Core_96 is QMD (Folding), and Core_ca used to be SPG (Genome). A newer core, Core_a0 is Gromacs 33 (Folding). See also: Cores
The core version can be found in the core log file, which is deleted if the unit uploads on the very first try, so on some systems which have permanent connections to the Internet, the core version will only rarely be available at indices other than the current one.
Misc1b
These numbers are present in queue.dat, but it isn't known for sure what they are. Most likely they are related to the revision levels of the client which are suitable for this work unit.
The other numbers are Misc1a and Misc3b
Work Unit Size
This is used as one of the checks for a proper work unit download. It is the size in bytes of the wudata_<XX>.dat file.
z192
These fields are present in queue.dat and usually only contain zeros.
Some fields, like z192, z224 and z7152 are most likely reserved for future use. Whereas other fields are mostly likely padding, or sometimes contain unknown values, e.g. z500 and z528.
grep "unknown stuff" qd.c /* There is still sometimes unknown stuff in bytes 500-507 and 528 */
Project Number
This is the number of the project which the work unit is part of.
Run
If the unit is not using Core_ca (the Genome core), these numbers (Run, Clone & Generation), along with the project number, uniquely identify the work unit. If it is necessary to notify Stanford of the work unit ID, those four numbers (project, run, clone, generation) should always be given.
Clone
If the unit is not using Core_ca (the Genome core), these numbers (Run, Clone & Generation), along with the project number, uniquely identify the work unit. If it is necessary to notify Stanford of the work unit ID, those four numbers (project, run, clone, generation) should always be given.
Generation
If the unit is not using Core_ca (the Genome core), these numbers (Run, Clone & Generation), along with the project number, uniquely identify the work unit. If it is necessary to notify Stanford of the work unit ID, those four numbers (project, run, clone, generation) should always be given.
Issued
This time stamp is placed on the work unit by the work server when it assigns the unit. It is an epoch 1970 value, based on the server's clock. The servers lately have been accurately synchronized with NTP. If a unit, for any reason, gets lost so it isn't either completely finished or ready for upload when the next unit is requested, the server will often notice the previous assignment and send the same unit again, with the original issue time stamp.
z224
These fields are present in queue.dat and usually only contain zeros.
Some fields, like z192, z224 and z7152 are most likely reserved for future use. Whereas other fields are mostly likely padding, or sometimes contain unknown values, e.g. z500 and z528.
grep "unknown stuff" qd.c /* There is still sometimes unknown stuff in bytes 500-507 and 528 */
Machine ID
This is the MachineID as configured when the unit started. When the MachineID and UserID are added together and sent to the server with an uploaded unit, the client uses the MachineID which is current at that time.
Server IP
This is the IP address of the data server from which the work unit was downloaded. It is also the address to which the unit must eventually be uploaded if it is still active.
The Server IP for Folding@Home clients before v3.0 the value was stored at 040 bytes from the start of each queue index. Starting at byte 264 of each index is the Server IP for client v3.0 and later. The v3.0 and later clients also store the port number.
See also: Work Server
Server Port
This is the port number of the data server from which the work unit was downloaded.
The Server IP for Folding@Home clients before v3.0 the value was stored at 040 bytes from the start of each queue index. Starting at byte 264 of each index is the Server IP for client v3.0 and later. The v3.0 and later clients also store the port number.
Work Unit Type
This actually isn't a work unit type at all, but simply a text message which the data server can insert in a downloaded unit. It usually just says "Folding@Home", and sometimes nothing at all.
User Name
This is the UserName as configured when the unit started. The UserName actually sent to the server when the unit is uploaded is what is current at that time.
Team Number
This is the TeamNumber as configured when the unit started. The TeamNumber actually sent to the server when the unit is uploaded is what is current at that time.
CPU ID
This ID is used by the server to identify the user's machine, and to validate the work unit when it is returned. The number stored in queue.dat, is really the sum of the assigned UserID and the configured MachineID, as it was when the unit started. The ID actually sent to the server when the unit is uploaded is what is current at that time on the machine which does the upload. Ideally, it should match the ID to which the unit is assigned, to within the allowed configurable range of the MachineID, or the uploaded unit might be rejected. Recent experiments with transferring work among machines have shown the servers usually to be more permissive, but relying on this would probably be a bad idea.
Benchmark
When the client starts, it calculates this benchmark number. It is a measure of floating point processing power, but it is also strongly affected by any other programs which happen to be running on the machine at the time. It's normal for the benchmark number to vary over a wide range.
Misc3b
These numbers are present in queue.dat, but it isn't known for sure what they are. Most likely they are related to the revision levels of the client which are suitable for this work unit. This particular number has a comment in the qd source code which says: "Misc3b (unused as of v3.24) (LE)".
The other numbers are Misc1a and Misc1b
CPU Type
The CPU and OS types are detected by the client and sent to the servers when requesting assignments. They can influence what sort of work will be assigned, and which core URL is given to the client. Each of these types is reported as a pair of numbers, the first of which is a basic type defined by Cosm (See also Cosm), and the second of which is a subtype determined by the client. The most detail is available for Windows systems running on Intel CPUs. The numbers are sometimes stored in little-endian order in queue.dat, and sometimes in big-endian order, with no clearly consistent pattern.
The full set of numbers are: CPU Type, CPU Species, OS Type and OS Species.
The types defined by Cosm are documented at: Cosm API - Defines and Types
CPU Species
The CPU and OS types are detected by the client and sent to the servers when requesting assignments. They can influence what sort of work will be assigned, and which core URL is given to the client. Each of these types is reported as a pair of numbers, the first of which is a basic type defined by Cosm, and the second of which is a subtype determined by the client. The most detail is available for Windows systems running on Intel CPUs. The numbers are sometimes stored in little-endian order in queue.dat, and sometimes in big-endian order, with no clearly consistent pattern.
The full set of numbers are: CPU Type, CPU Species, OS Type and OS Species.
OS Type
The CPU and OS types are detected by the client and sent to the servers when requesting assignments. They can influence what sort of work will be assigned, and which core URL is given to the client. Each of these types is reported as a pair of numbers, the first of which is a basic type defined by Cosm (See also Cosm), and the second of which is a subtype determined by the client. The most detail is available for Windows systems running on Intel CPUs. The numbers are sometimes stored in little-endian order in queue.dat, and sometimes in big-endian order, with no clearly consistent pattern.
The full set of numbers are: CPU Type, CPU Species, OS Type and OS Species.
The types defined by Cosm are documented at: Cosm API - Defines and Types
OS Species
The CPU and OS types are detected by the client and sent to the servers when requesting assignments. They can influence what sort of work will be assigned, and which core URL is given to the client. Each of these types is reported as a pair of numbers, the first of which is a basic type defined by Cosm, and the second of which is a subtype determined by the client. The most detail is available for Windows systems running on Intel CPUs. The numbers are sometimes stored in little-endian order in queue.dat, and sometimes in big-endian order, with no clearly consistent pattern.
The full set of numbers are: CPU Type, CPU Species, OS Type and OS Species.
Expires
This value stored in queue.dat is the allowed time to return in seconds for the particular WU.
z500
These fields are present in queue.dat and usually only contain zeros.
Some fields, like z192, z224 and z7152 are most likely reserved for future use. Whereas other fields are mostly likely padding, or sometimes contain unknown values, e.g. z500, z528 and z548.
grep "unknown stuff" qd.c /* There is still sometimes unknown stuff in bytes 500-507, 528 and 548
Assignment Info Present
This value is either 0x00 (0) or 0x01 (1). It is a flag to indicate if there is Assignment Info present. It can be stored in either Little-Endian or Big-Endian.
The three related fields are: Assignment Info Present, Assignment Timestamp and Assignment Info.
See also: Assignment Server and Work Server
Assignment Timestamp
This time stamp and data word are sent to the client by the assignment server along with the IP address of the work server and other information. The data word is a checksum derived from the IP address and the time stamp. The client sends all three words to the work server as validation of the assignment. These values can be stored in queue.dat in either little-endian or big-endian byte order. It is unknown why it can be either way.
The three related fields are: Assignment Info Present, Assignment Timestamp and Assignment Info.
See also: Assignment Server and Work Server
Assignment Info
The time stamp and data word are sent to the client by the assignment server along with the IP address of the work server and other information. The data word is a checksum derived from the IP address and the time stamp. The client sends all three words to the work server as validation of the assignment. These values can be stored in queue.dat in either little-endian or big-endian byte order. It is unknown why it can be either way.
The three related fields are: Assignment Info Present, Assignment Timestamp and Assignment Info.
See also: Assignment Server and Work Server
Collection Server IP
This is the collection server IP address, which is not always present. If it is given, it identifies an alternate server to which the results can be returned if there are too many errors attempting to upload to the actual work server. If work is returned to the collection server, credit for it will occasionally be delayed in the Stanford statistics, but this is better than having the work deleted by the client if its deadline expires before the server can be reached successfully.
See also: Collection Server
Download Started
This field is usually absent if a collection server address is given for this unit. It seems to be a date roughly corresponding to the end of the download, from the work server's perspective. It is an epoch 2000 value, most likely based on the server's clock.
z528
These fields are present in queue.dat and usually only contain zeros.
Some fields, like z192, z224 and z7152 are most likely reserved for future use. Whereas other fields are mostly likely padding, or sometimes contain unknown values, e.g. z500, z528 and z548.
grep "unknown stuff" qd.c /* There is still sometimes unknown stuff in bytes 500-507, 528 and 548
SMP Cores
Number of SMP cores (as of v5.91)
The SMP cores are the number of cores which the SMP client detects at startup.
This is appears to only be stored by the F@H client v5.91 and up.
The SMP client will startup with some messages like:
$ ./fah5 -local -verbosity 9 Using local directory for configuration Note: Please read the license agreement (fah5 -license). Further use of this software requires that you have read and accepted this agreement. Using local directory for work files 2 cores detected --- Opening Log file [March 4 00:56:00] [...]
"SMP cores" refers to the column on Stanfords serverstat page.
z548
These fields are present in queue.dat and usually only contain zeros.
Some fields, like z192, z224 and z7152 are most likely reserved for future use. Whereas other fields are mostly likely padding, or sometimes contain unknown values, e.g. z500, z528 and z548.
grep "unknown stuff" qd.c /* There is still sometimes unknown stuff in bytes 500-507, 528 and 548
Due
This time is calculated by the client when it downloads a unit. It is determined by adding the "begin" time to the expiration period, if this expiration data is sent as part of the work unit. Genome units had no deadlines, nor do a few Folding units designated for machines which are either slow or only infrequently connected to the Internet. All other Folding units do, but not all work units have the expiration period fields filled in. The stored time is an epoch 2000 value, based on the local machine's clock.
There are actually two sorts of deadline associated with a work unit. This one, which is the only one known to the client, is what the Stanford project summary web page calls the "Final Deadline", after which time the client may delete the unit and no credit will be given even if it is completed and returned. The other deadline, shown on the project summary as "Preferred", indicates when the unit will be considered late enough that the server might send another copy of it to someone else, which means that a unit returned after that time might have little scientific value.
NOTE that if the machine clock runs, or is set, forward to a time past the "due" date, the client might think the unit is past due, and delete it.
Packet Size Limit
This is a packet size limit, used to determine how much memory should be allocated when returning results. Its default size seems to be about five megabytes, but if "large units" are selected, the client will set the value to ten times that size. If the actual results file is bigger than the packet limit, the client will be unable to return it to the server.
Upload Failures
The client uses this field to decide when to try sending results to the collection server instead of to the actual work server. It is the value of the number of times an upload for this WU has already failed.
Performance Fraction
This value is calculated by the client as a benchmark of the system's ability to complete work units quickly. It is a sliding window average of the fraction of the deadline time remaining when a unit is completed, weighted over the recorded number of units. The number of units is capped at four, exactly as it is for the network download and upload rates.
Performance Fraction Units
This field stores the number of WUs the Performance Fraction is weighted over.
Download Rate
This rate is measured by the client as a benchmark of system network performance. It is a sliding window average weighted over the recorded number of units. This number is capped by the client at four, so the average tends to track more recent performance. It doesn't mean that only the last four units are averaged, but rather that the stored value is weighted four times greater than the value from a new unit, so in fact it determines the characteristic rate at which the effects of older units decay.
Download Rate Units
This field stores the number of WUs the Download Rate is weighted over.
Upload Rate
This rate is measured by the client as a benchmark of system network performance. It is a sliding window average weighted over the recorded number of units. This number is capped by the client at four, so the average tends to track more recent performance. It doesn't mean that only the last four units are averaged, but rather that the stored value is weighted four times greater than the value from a new unit, so in fact it determines the characteristic rate at which the effects of older units decay.
Upload Rate Units
This field stores the number of WUs the Upload Rate is weighted over.
All Zeros
These fields are present in queue.dat and usually only contain zeros.
Some fields, like z192, z224 and z7152 are most likely reserved for future use. Whereas other fields are mostly likely padding, or sometimes contain unknown values, e.g. z500 and z528.
grep "unknown stuff" qd.c /* There is still sometimes unknown stuff in bytes 500-507 and 528 */
Structure
The structure of the queue.dat defined in the qd.c source code:
/* Structure of <queue.dat> file */
typedef unsigned int u32;
typedef unsigned short u16;
struct qf
{ u32 version; /* 0000 Queue (client) version (v2.17 and above) */
u32 current; /* 0004 Current index number */
struct qs
{ u32 stat; /* 000 Status */
char z004[4]; /* 004 Pad for Windows, others as of v4.01 */
u32 tdata[8]; /* 008 Time data (epoch 0000 1jan00 UTC) */
u32 svr1; /* 040 Server IP address (until v3.0) */
u32 ustat; /* 044 Upload status */
char url[128]; /* 048 Web address for core downloads */
u32 m176; /* 176 Misc1a */
u32 core; /* 180 Core_xx number (hex) */
u32 m184; /* 184 Misc1b */
u32 dsiz; /* 188 wudata_xx.dat file size */
char z192[16];
union
{ struct
{ char proj[2]; /* 208 Project number (LE) */
char run[2]; /* 210 Run (LE) */
char clone[2]; /* 212 Clone (LE) */
char gen[2]; /* 214 Generation (LE) */
char issue[2][4]; /* 216 WU issue time (LE) */
} f; /* Folding@home data */
struct
{ char proj[2]; /* 208 Project number (LE) */
u16 miscg1; /* 210 Miscg1 */
char issue[2][4]; /* 212 WU issue time (LE) */
u16 miscg2; /* 220 Miscg2 */
u16 miscg3; /* 222 Miscg3 */
} g; /* Genome@home data */
} wuid; /* 208 Work unit ID information */
char z224[36];
char mid[4]; /* 260 Machine ID (LE) */
u32 svr2; /* 264 Server IP address */
u32 port; /* 268 Server port number */
char type[64]; /* 272 Work unit type */
char uname[64]; /* 336 User Name */
char teamn[64]; /* 400 Team Number */
char uid[8]; /* 464 Stored ID for unit (UserID + MachineID) (LE or BE, usually BE) */
char bench[4]; /* 472 Benchmark (as of v3.24) (LE) */
char m476[4]; /* 476 Misc3b (unused as of v3.24) (LE) */
u32 cpu_type; /* 480 CPU type (LE or BE, sometimes 0) */
u32 os_type; /* 484 OS type (LE or BE, sometimes 0) */
u32 cpu_spec; /* 488 CPU species (LE or BE, sometimes 0) */
u32 os_spec; /* 492 OS species (LE or BE, sometimes 0) */
u32 expire; /* 496 Allowed time to return (seconds) */
char z500[8];
char aiflag[4]; /* 508 Assignment info present flag (LE or BE) */
char aitime[4]; /* 512 Assignment timestamp (LE or BE) */
char aidata[4]; /* 516 Assignment info (LE or BE) */
char csip[4]; /* 520 Collection server IP address (as of v5.00) (LE) */
char dstart[4]; /* 524 Download started time (as of v5.00) (BE) */
char z528[16];
char cores[4]; /* 544 Number of SMP cores (as of v5.91) (BE) */
char z548[140];
u32 due[4]; /* 688 WU expiration time */
u32 plimit; /* 704 Packet size limit (as of v5.00) */
u32 uploads; /* 708 Number of upload failures (as of v5.00) */
} entry[10]; /* 0008 Array of ten queue entries */
u32 pfract; /* 7128 Performance fraction (as of v3.24) */
u32 punits; /* 7132 Performance fraction unit weight (as of v3.24) */
u32 drate; /* 7136 Download rate sliding average (as of v4.00) */
u32 dunits; /* 7140 Download rate unit weight (as of v4.00) */
u32 urate; /* 7144 Upload rate sliding average (as of v4.00) */
u32 uunits; /* 7148 Upload rate unit weight (as of v4.00) */
char z7152[16]; /* 7152 (as of v5.00) ...all zeros after queue conversion... */
} qbuf;
/* There is still sometimes unknown stuff in bytes 500-507 and 528 */
Links
- queue.dat documentation for qd
- current qd homepage
- old qd homepage
- qd description page (now merged into the queue.dat documentation for qd)
- Folding-community: QUEUE.DAT dump and benchmark utilities
