Date: Wed, 15 Jul 1998 22:12:20 +1000 (EST) From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Losing clock interrupts Message-ID: <199807151212.WAA23486@gsms01.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
I'm running parallel IP between a 486 DX2-50 and a 386SX-25. Both
systems have IDE disks. I find that network-intensive activities are
causing clock interrupts to be lost. Dropping the MTU helps, but has
adverse effects on the throughput (admittedly the system's own
calculated throughput looks very good when the clock is basically
stopped).
I've added some code to the IRQ0 handler to capture timestamps on the
486 system and have come up with the following:
- With no system load, the latency (to the beginning of hardclock())
averages ~12usec (~50usec worst case).
- The IDE disk handler has minimal impact (the worst case went up to
~75usec latency with ~2.5MB/sec disk I/O and multi-block-16)
- LPIP is a real killer. With an MTU of 512, I'm getting latencies
>8.5msec sending data and >9.8 msec receiving data.
In all cases, the hardware interrupt is received quite quickly - the
latencies seem to be ~6usec up to the point where DS is reloaded. The
delay is caused by SPL inhibition (most of the LPIP code runs above
splclock()).
My initial understanding was that when an interrupt was masked,
it re-entered at Xresume{n} when it was unmasked. This would mean
that I could add some code between Xintr0 and Xresume0 that would
count the number of hardware interrupts and modify hardclock() to
handle being called less than once per tick.
Unfortunately, my timing results show that the soft interrupt entry
is also via Xintr{n} which renders this approach useless. (It also
explains the vec0 code in i386/isa/icu.s).
I accept that a slow 386 on the other end of the link doesn't help,
but I can't readily replace that machine. (And it's an ancient
laptop with no other `fast' IP-capable interfaces - I don't count
16450 UARTs as fast).
Can anyone offer any suggestions on how to either:
1) allow clock interrupts to be handled (and hardclock() run) whilst
sending/receiving an LPIP packet.
2) Count real clock interrupts (so hardclock() could compensate when
it finally gets a look in)
3) Soup up LPIP so it doesn't hog as much CPU.
On the latter point, has anyone looked at making LPIP transmit bytes
instead of nybbles? This should roughly halve the time to
send/receive a packet. The biggest problem would seem to be
negotiating who would transmit at any point in time.
Peter
--
Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807151212.WAA23486>