diff options
Diffstat (limited to 'README.txt')
| -rw-r--r-- | README.txt | 22 |
1 files changed, 13 insertions, 9 deletions
@@ -23,7 +23,7 @@ DESCRIPTION The <bits-per-sec> argument is optional. If it's not given, the bit rate will be set from SLOWBAUD_BPS in the environment, or a built-in default of 2400 if - not set. + that's not set. OPTIONS bits-per-sec @@ -75,10 +75,8 @@ EXIT STATUS to open /dev/null for writing). NOTES - Timing accuracy depends on your OS, kernel config (HZ and/or NO_HZ on Linux), - and system load. No "fancy" techniques like realtime scheduling or hardware - event timers are used. At bitrates up to 57600, on a typical unloaded Linux - system, the timing should be at least 99.7% accurate. + The timing inaccuracy will almost always result in the bitrate being slightly + too slow. We can't really insert a delay between the bits of a byte, since I/O is done with byte granularity. For calculation purposes, <bits-per-sec> is divided by @@ -91,14 +89,20 @@ NOTES works well, and the CPU overhead is barely noticeable (at least on reasonably fast modern systems). - The timing inaccuracy will almost always result in the bitrate being slightly - too slow. + Timing accuracy depends on your OS, kernel config (HZ and/or NO_HZ on Linux), + and system load. Also on the amount of data, since the timing loop is + self-regulating (the first few bytes will have less accurate timing than later + ones). No "fancy" techniques like realtime scheduling or hardware event timers + are used. At bitrates up to 115200, on an unloaded Linux system, the timing + should be at least 99.9% accurate. At higher bitrates, accuracy will decrease. Timing is more accurate on Linux than OSX. It's done with getitimer() and sig‐ wait(). This works out to be slightly more accurate than using usleep() on both Linux and OSX. It would be possible to use the realtime timer_create() and clock_gettime() API on Linux, for possibly even better accuracy, but OSX - doesn't have these (and I want to be portable). + doesn't have these (and I want to be portable). On an unloaded OSX system, the + accuracy gets steadily worse as you go above 57600bps. There's also more CPU + overhead on OSX. If this were a truly useful application, it would be worth trying to increase accuracy further, with realtime process scheduling. I didn't do this because @@ -120,4 +124,4 @@ COPYRIGHT slowbaud is copyright 2021, B. Watson <yalhcru@gmail.com>. Released under the WTFPL. See http://www.wtfpl.net/txt/copying/ for details. -0.0.1 2021-07-22 SLOWBAUD(1) +0.0.1 2021-07-23 SLOWBAUD(1) |