Serial Communication Slow, Increase Serial Port Interrupt Priority?
Günter Wirth
I wrote an application to send and receive serial data. I always write a
block of data and wait then for an ACK. With Windows 2000 that task is about
20% faster than with Windows XP.
After recording the data flow, I detect that the pause after the ACK and the
next data block is the reason for the problem.
That's why I think the problem is the priority of the serial port interrupt.
Is it possible to increase the prioity by programm or registry?
Regards,
Günter
Kirk Ferdmann
news:3f7d368f$0$12889$9b62...@news.freenet.de...
Interrupts associated with COM1/COM2 have not changed in nearely 20 years or
so :o) So that's not your problem. I hope you realize that neither one of
the OS you've mentioned is real-time. The latency can be result of many
factors: version of HAL, your actual hardware etc. Try to use portmon
(http://www.sysinternals.com/ntw2k/freeware/portmon.shtml). It might give
you better insight into your problem.
-Kirk
Günter Wirth
> Interrupts associated with COM1/COM2 have not changed in nearely 20 years
or
> so :o) So that's not your problem. I hope you realize that neither one of
> the OS you've mentioned is real-time. The latency can be result of many
> factors: version of HAL, your actual hardware etc. Try to use portmon
> (http://www.sysinternals.com/ntw2k/freeware/portmon.shtml). It might give
> you better insight into your problem.
I used a hardware port monitor to find out the delay after the ACK and
sending
the next block. It seems like the sign is in the buffer of windows, but my
application needs more time to read it. I still tried to increase the
priority of
my application and the threads, but without results.
Regards,
Günter
Slava M. Usov
news:blr6b6$vqp$03$1...@news.t-online.com...
[...]
> It seems like the sign is in the buffer of windows, but my application
> needs more time to read it. I still tried to increase the priority of my
> application and the threads, but without results.
Make sure that the comm timeouts are set properly.
S
Gary G. Little
generally set the port timing and timeouts incorrectly. Normally you would
have a buffer full when you do a read, but sometimes the buffer isn't full,
so you time out waiting for the buffer to fillup. Look at how you have
timing set on the serial port.
--
Gary G. Little
Seagate Technologies, LLC
"Slava M. Usov" <stripit...@gmx.net> wrote in message
news:us3fx9$iDHA...@TK2MSFTNGP09.phx.gbl...
Günter Wirth
because the same programm is slower on Windows XP, than on Windows 2000 I
think the problem is the operating system.
Is there a way to increase the priority of the serial port interrupt handler
of windows?
Regards,
Günter
"Gary G. Little" <gary.g.lit...@seagate.com> schrieb im Newsbeitrag
news:Ttdgb.3380$mL7...@newssvr23.news.prodigy.com...
Slava M. Usov
> because the same programm is slower on Windows XP, than on Windows 2000 I
> think the problem is the operating system.
Do you set the timeouts explicitly? If not, their defaults are persistent
and may be different.
> Is there a way to increase the priority of the serial port interrupt
> handler of windows?
The IRQL that is assigned to an interrupt vector is determined by the PnP
manager. Looking at my W2003 system, it appears that IRQLs are simply the
corresponding IRQ number. Thus having a serial port connected to IRQ 4
results in the IRQL of 4, which is below any other IRQL except the
keyboard's and the software levels.
I've found a few web pages saying that you can prioritize that manually by
creating a value in HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl,
but they all describe that so vaguely that I have serious doubts about it.
Frankly, I do not believe that IRQ priority has anything to do with your
problem. I've seen too many people stating poor serial performance and
asking how FIFO can be disabled, IRQL boosted, and so on, while their
problems were actually caused by wrong comm timeouts and inefficient app
design.
S
Gary G. Little
applications. It doesn't necessarily mean that XP has a problem, but that
the problem with your application simply does not appear in 2000 but does
appear in XP. I dare say Server 2003 will show the same problem as XP.
The place to fix the problem is your application. Setting thread priorities
or moving IRQL will only obfuscate the issue.
--
Gary G. Little
Seagate Technologies, LLC
"Günter Wirth" <g.wirth...@extec.de> wrote in message
news:bltq42$5oh$01$1...@news.t-online.com...
Kirk Ferdmann
> "Günter Wirth" <g.wirth...@extec.de> wrote in message
> news:bltq42$5oh$01$1...@news.t-online.com...
>
> > because the same programm is slower on Windows XP, than on Windows 2000
I
> > think the problem is the operating system.
>
> Do you set the timeouts explicitly? If not, their defaults are persistent
> and may be different.
That's very good advice. I had such experience when my company started to
use DigiBoards instead of RocketPort serial controller cards. The
DigiBoard's driver had a different set of deafult settings so my application
did not work properly. I would not recommend to rely on driver's defaults
(and not just for timeouts)
> > Is there a way to increase the priority of the serial port interrupt
> > handler of windows?
>
> The IRQL that is assigned to an interrupt vector is determined by the PnP
> manager. Looking at my W2003 system, it appears that IRQLs are simply the
> corresponding IRQ number. Thus having a serial port connected to IRQ 4
> results in the IRQL of 4, which is below any other IRQL except the
> keyboard's and the software levels.
IRQL assignment depends on a version of HAL your machine is using. If you
are using PIC based HAL the allocation schema is to substract the IRQ# from
27. In the case of APIC based HAL the allocation schema is much more complex
and involves some kind of round robin algorithm. So the real IRQL of IRQ 4
(for the COM1) might be pretty much anything in this case. I think (but I'm
not sure) that MP and SP HALs also employ different IRQL allocation
algorithms.
> [...]
> Frankly, I do not believe that IRQ priority has anything to do with your
> problem. I've seen too many people stating poor serial performance and
> asking how FIFO can be disabled, IRQL boosted, and so on, while their
> problems were actually caused by wrong comm timeouts and inefficient app
> design.
Excelently put. But I think he is just not willing to accept responsibility
for his bugs. Why is it so common to respond with "it used to work, so it's
not my bug"?!
-Kirk
J.P. Iribarren
<3f7d368f$0$12889$9b62...@news.freenet.de>...
>Hi,
Hello Günter,
>I wrote an application to send and receive serial data. I always write
>a block of data and wait then for an ACK. With Windows 2000 that task
>is about 20% faster than with Windows XP.
Most probably different default settings for transmit and receive FIFOs.
>After recording the data flow, I detect that the pause after the ACK
>and the next data block is the reason for the problem.
>
>That's why I think the problem is the priority of the serial port
>interrupt.
Nope, it's probably not the cause. You came to this conclusion because
you think that as soon as you see the ACK byte (with a protocol analyzer
on the serial line I suppose), the UART has generated the associated
interrupt, and the delay comes from a delayed processing of this
interrupt. I guess this is not the case.
>Is it possible to increase the prioity by programm or registry?
If the problem comes from what I have in mind, you won't even get 1% by
switching to realtime priority.
Most probably, you are using the default settings for the comm port
FIFOs. When receiving data, the UART works this way: a receive interrupt
is only generated by one of the two following conditions:
a) at least <rx threshold> characters have been received and are waiting
in the UART rx FIFO,
or
b) at least one character has been received and the UART reached its rx
timeout (4 characters time IIRC).
So, if the rx threshold of your UART is set to anything more than 1
character, when you receive a single ACK byte, the UART will delay the
interrupt by 4 character times. This is hardware, and this is why
increasing the priority of the associated interrupt won't help. If the
chip doesn't signal anything, the CPU won't be interrupted, whatever the
priority of the interrupt.
Try to set the rx FIFO threshold to 1 and see how it works. The PDF doc
for the 16C550 is available on National Semiconductor Web site. Have a
look at the "FIFO" section for further details. Depending on the needs
of your application, you may want to lower the tx FIFO threshold as
well.
Hope this helps,
--
Jean-Paul Iribarren (aka JPI)
Anti-spam: ma véritable adresse électronique ne comporte pas de
chiffres;donc...
Anti-spam: my real e-mail address has no digits; consequently...
Günter Wirth
Thank you very much for your detailed explanation!
Regards,
Günter
"J.P. Iribarren" <fami...@free.fr> schrieb im Newsbeitrag
news:bm0df6$7qe$1...@s1.read.news.oleane.net...