Re: Palatable Windows IO using Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 9 Apr 2006 06:50:23 -0700, Steve wrote:

> It is interesting the opinions that are formed based on one's experiences. 
> Mine is at least in part formed because in the past I have had to rewrite 
> drivers that handled one character at a time to process as many as possible 
> at a time due to performance issues.
>
> In one case, when communicating with an Allen Bradley PLC using DF1 
> protocol, I found that the driver that handled one character at a time used 
> up a significant part of the available CPU time.  Enough that the computer 
> was observed to be very sluggish.
> 
> The DF1 protocol uses markers (DLE) to mark key locations in the data 
> stream.  By using a "read until character" function instead of reading one 
> character at a time, the CPU overhead was significantly reduced, and the 
> system was no longer sluggish.

How would you tell that to the driver? Do you mean a true driver here or
merely a program that uses an OS serial driver? I meant the later. Talking
about drivers, you are absolutely right. Interrupts are very expensive on
wintel platform. I had to redesign one driver (an ISA transputer link
driver) for a similar reason. The card produced an interrupt per byte at up
to 1Mbaud...

> Most of the applications I have worked on make heavy use of the CPU and are 
> time critical (but not safety critical).  Minimizing the processor overhead 
> used by communication is often a goal.
> 
>>>> Windows ReadFile isn't always blocking, it can be asynchronous, see
>>>> "overlapping" I/O in MSDN description of ReadFile.
>>>>
>>> I've been through the windows overlapped I/O for serial communications. 
>>> In
>>> my opinion it's a royal pain in the ass.
>>
>> Yes. In my opinion it is overkill to use overlapped I/O for serial
>> connections. Though if you have 1000 devices to handle simultaneously,
>> there might be no other choice. In RSX and VAX, where the idea of
>> asynchronous I/O seems was borrowed from, it worked well. I also think 
>> that
>> overlapped I/O and asynchronous system trap could nicely fit to Ada's
>> protected objects. The interface to overlapped I/O is so clumsy because 
>> API
>> is in C, it should be in Ada! (:-))
> 
> On NT/XP for full duplex communication, you really have two choices:
>   Use non-blocking I/O (poll)
>   Use overlapped I/O

I prefer two threads, one does blocking read (incoming bytes stream),
another blocking write (outgoing packets), it works well. Overlapped I/O is
too clumsy, then the read buffer cannot be accessed anyway when the
operation is pending.

> The clumsy interface has no relation to the choice of language of the API. 
> And it shouldn't.  It is based on the design of the driver.  In the good (or 
> bad?) old days, the OS interfaces used to be described in a language neutral 
> manner... as it should be.

How can you do it language neutral? The problem is that asynchronous I/O
inherently requires concurrency. If the language does not support
concurrency, you simply cannot comprehensively describe what's going on.

> When I had to make duplex serial communications work right on NT, I found an 
> article descrbing how great it was that NT could do overlapped I/O, and how 
> it was something new and wonderful.  I was left with the impression that the 
> developer had only done the D part of R&D and thought this was a great new 
> feature.  I found it to be a clumsy feature that was working around a poor 
> driver implementation.  I had the same impression when Microsoft "invented" 
> multi-threaded programming... after I had already been using multi-tasking 
> systems for years.

I started on RSX-11 and VAX-11, so to me it was a shock to see for the
first time how many processes were running on an idle Unix machine. Slowly
I adapted to the idea that each mouse button needs a separate process to
deal with (:-)) Windows is somewhere between. It is unfair to blame alone
Microsoft for all mess. It was Unix first, which destroyed the market of
operating systems. We have what we have deserved.

>> I didn't saw any significant difference when using synchronous vs.
>> asynchronous read for serial devices. Taking into account serial 
>> connection
>> speed I doubt one could notice it. A more interesting case is socket I/O.
>> Our commercial software reads from sockets using 1 byte buffer and 
>> blocking
>> read. Recently we did elaborated time measurements under Windows XP and
>> Server 2003 for stream uni- and multicast sockets. It was all but easy,
>> because of quite flawed design of Windows time services. But that's a
>> different story. Anyway, our experiments have shown that the bottleneck
>> wasn't communication. We tested publisher / subscriber services of our
>> product and have noticed that the communication layer by margin 
>> outperforms
>> other (local) parts. Roughly, global mutexes and context switches are much
>> worse than I/O APIs, even if the former are used per data block and the
>> later per byte.
> 
> Since you're using Windows XP and Server 2003, you're probably using recent 
> hardware, which is fast enough that you may not see an overall time 
> difference.  If you use a high resolution performance counter to do you're 
> timing you are much more likely to find a difference.
> 
> I started working with networking on NT on Pentium 166 machines (or 
> slower...

Once I managed to install Windows NT 4.0 on a 486DX 66MHz / 12Mb. It took
about one day. The system booted in 10 minutes or so. I still remember VMS,
which served 6 interactive users having 4Mb memory. It had DEC Ada too!
(:-)) 

> it's been long enough that I can't remember).  On those machines 
> the time difference was more significant.

Actually it worked well on a Pentium 133 under Windows NT 4.0. COM port
isn't fast enough to break it down. In fact, in one case we had to slow
down the PC side, because the device crashed when PC had written too fast.

I'm too lazy to look into Kernel32.dll, but I guess, that an ReadFile call
isn't that expensive. I suppose that there is an OS-allocated buffer in the
process space, so ReadFile does nothing extraordinary. Because the input is
buffered, it makes little sense to do it again. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de