I’m not surprised at the differentials in the thread priorities, but I’m
afraid you still have things screwed up somewhere in your code.
I have DLL code that takes MIDI output from programs and spits it to serial
ports at 38400, and MIDI cares about things like 1ms of jitter. On my old
test boxes with real serial ports I can set up a test with periodic outputs
and see that my jitter is well under 1ms when sending 3 byte MIDI packets.
So that means that path length from when I submit the WriteFile with 3 bytes
to when it comes out is pretty short, although that is a little hard to
measure directly. Although I guess I could set up a wraparound test and
measure latency from a 3 byte serial input to a 3 byte serial output on the
same or another port. I’d expect it to be on the order of 1100us or less at
38400, with most of that time the time to receive the 3 bytes.
Now, it could be your boxes have royally screwed up hardware serial ports,
but I doubt that a little. There were some such boxes, but that was long
ago (as far as I know). I certainly haven’t run into one myself.
I’m still suspecting that you son’t have the serial timeouts and other
options set right on your serial port setup. Getting those wrong can result
in the sort of things you are seeing, where an incomng packet ends up
waiting for a while before it shows up.
Oh! I just remembered - it could also be how you are doing your receives.
You should do a receive with an essentially infinite timeout for a SINGLE
byte. When that is satisfied, check to see how many bytes are available in
the buffer, and do a read for exactly that many bytes. If you ask for a 10
byte buffer and only 3 bytes are available, the read won’t complete until
the inter-character delay times out. (There is another way to do this with
a single read and the right timeouts and some other op, but I’ve forgotten
exactly how, and I’m too lazy to go pull the code out of the archive
server.)
As for USB serial devices, most all of them on receive actually generate
packet delays. They try to glob up several characters before putting a
packet on the USB line to keep the USB traffic down, since they all send in
bulk mode. Some of them have interfaces that you can call to remove this
globbing function and send characters when they appear. One interface I
worked with had a globbing delay around 40ms as best I recall, but it could
be set to zero or to a much longer interval.
Let’s see. On reading your reply again, I think your basic problem in
turnaround time, right? You have to get a response back to the thing within
X ms or it times out? So if that is the case, you have two potential
problems - globbing delays on the input path, and any possible delays on the
output path.
For the output path, you should essentially have zero delay on a hardware
serial port… When you send a byte it should show up on the wire within
microseconds. Ideally there won’t be a globbing delay with a USB device,
but there could be. If you are set up to watch modem signals like CTS, then
there are delays in monitoring them. I’m hoping your device doesn’t use
flow control, so you should be able to set up the serial port options to
ignore hardware flow control.
For the input path, there is any globbing delay in the USB device, plus any
inter-character delay that you have set up when you set the serial port
timeouts. (And there is some value set by default, although I don’t remember
what. You need to override it.)
It sounds to me like you may have had a priority problem on the output
thread that you fixed (or got around) with priorities. I think you still
have problems on the input side. Part of this might be asking for X bytes
when only globbing delays.
BTW, as this is a DOS conversion, I hope you don’t have anything running in
a buzz loop looking for input, or for things to do? If so, that could be a
BIG part of your problems. If you have this, you should spend a little time
on whatever is in the buzz loop and redo it to wait on events rationally.
Loren
