The Render Billed By The Second

The file is 4,466 bytes and its sha256 begins 08242dfe40bc2681. It holds 18 records, one for each vertical shot in a cafe shoot. Every one of the 18 reads done, so there is no failure half here, no retry pile and no error string anywhere in the file. 17 rows carry 5 fields: status, bytes, key, job and secs. 1 row carries 6, and the extra field is a checksum. Inside the 18 rows sit 55 string values, and 38 of them are distinct. The shape of the row is the only schema. Nothing in the file declares a version, a model, a rate or a date.

The secs column sums to 3,416. That is 56 minutes and 56 seconds of machine time across 18 renders. The column runs from 51 seconds to 393, an average of 189.8 and a median of 186.5. Three rows read exactly 51 seconds and two more read 52, so 5 of the 18 jobs finished inside a minute. No row carries the time it waited before it started. No row carries a cost. So 3,416 seconds is the time the machine ran, and the time the job took is a larger number that this file does not hold. A budget built on this column is a budget for compute, and it is not a budget for delivery.

The bytes column sums to 21,108,392 across the 18 renders. The lightest is 675,025 and the heaviest is 1,634,983, a spread of 2.42. Order the same rows by the clock and the spread is 7.71. The heaviest file in the run, 1,634,983 bytes, came off the fastest job at 51 seconds, which is 32,058 bytes per second of render. The lightest file, 675,025 bytes, came off a 176 second job, which is 3,835 bytes per second. One job returned 8.36 times the output per second that another did, and both are marked done. Divide the 21,108,392 by 18 and you get 1,172,688, a number that describes no render in the file.

17 of the 18 rows carry the same 5 fields. One carries a sixth, an md5, and it is the only checksum in the file. It is stored at 12 of its 32 characters. That row also holds the longest key at 86 characters where the other 17 run 73 to 81, and its filename carries an extra 8 character segment that no other key has. It is also the slowest job in the run at 393 seconds. Read that row on its own, 1 row out of 18, and it says the shot that took longest is the shot that came back with a hash attached and a name nobody else shares. The other 17 rows say done and nothing else.

4,466 bytes. 18 records. 18 of 18 reading done.

18 rows produce 55 string values, of which 38 are distinct, so 69 per cent of the strings in this file are new. The arithmetic is short. 18 keys, all distinct. 18 job ids, all distinct, 10 ending on one worker endpoint and 8 on the other. 1 status, written 18 times as done. 1 checksum. That is 38. Everything else in the file repeats. All 18 keys end on the take number 00001, so it is written 18 times and never leaves 1. Across the 18 shots sit 5 framing families: 4 close, 4 wide, 4 insert, 3 medium and 3 overhead. A shoot logged this way can be read two ways. Read the rows and you have 18 unique events. Read the columns and you have one word, done, in the only column that carries a verdict.

A render log is a promise that the next person can price the work without asking. This one prices compute and nothing else: bytes out, seconds in, done on every row. It cannot tell you what the shoot cost, because it holds no rate. It cannot tell you what the shoot took, because it holds no queue time. The probability that a log which measures only machine time is read as a record of project time is high, and the fix costs 1 field. On 210 energy systems deployed across Africa and Asia, a unit was signed off only when the machine hours, the serial and the site all resolved on the same day, and the meter was read against the same register every time. That is not bookkeeping. It is the difference between a meter and a memory. Bill the seconds you can defend, and say plainly which seconds they are. Keep more of yourself, for longer.