| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9959.1 | | SMURF::GILLUM | Kirt Gillum | Tue May 27 1997 18:36 | 13 |
|
Changing the FIFO size is fairly routine, and should be no cause for
alarm. My system routinely runs at full store and forward (copies the
whole packet over before transmitting).
Your system must be performing several transactions on the network AND
on other devices on the system to get the FIFO size to change. Qlogic
SCSI or NCR?
I would venture a guess that your system is very busy prior to the
changing of the FIFO size, and the act of changing the FIFO size
temporarily interrupts the activity enough for the system to continue.
|
| 9959.2 | Unhappy customer!!! | CSC32::A_LICAUSE | | Wed May 28 1997 09:14 | 13 |
|
So it does not alarm you that it could take a minute or more for this
activity to complete?
It certainly has the customer upset! He is unwilling to accept the
fact that at several times during his busy work schedule the systems
will freeze for this period of time.
Is there a parameter that will allow the system to initialize to 1024
rather than have to endure the periods inactivity to accomodate the
change by the system?
Al
|
| 9959.3 | | CSC32::bughunt.csc.cxo.dec.com::grubbs | | Wed May 28 1997 09:47 | 29 |
| I've got a totally unrelated customer (to the basenote)
reporting the same problem.
AS1000
DE500-XA (running at 10MB)
UNIX 4.0b
He says he sees 1 to 2 minute 'hangs' while the
fifo buffer threshold gets set higher and then
data flow continues on.
They do not see the same problem when they
run at 10Mb.
A similar system with a de500-AA has no such
delays under the same conditions and they do
see it setting the fifo buffer higher in
the same manner.
The only difference we can see other than the
difference in the enet cards is that the
system with the de500-aa is at one higher
firmware rev. Out of desperation they are
upgrading the de500-xa system to the higher
firmware version to see if it helps.
IPMT?
--Bert
|
| 9959.4 | | SMURF::GILLUM | Kirt Gillum | Wed May 28 1997 12:55 | 20 |
|
<So it does not alarm you that it could take a minute or more for this
<activity to complete?
No, it doesn't alarm me that the FIFO size changes. I guess I should
have said that.
The Ethernet driver is behaving as designed. I don't think the driver
is the source of your troubles. The reset of the hardware completes in
under 200 msec. If there's a larger delay associated with the reset,
it's due to the retransmit capabilities of the higher layer software.
When the system's busy, it takes time for the Ethernet driver to adjust
the hardware to work optimally. For all the systems that we support
under all loads, the driver adjusts the hardware to work the best it
can.
There currently is no means for setting the FIFO threshold via ioctl,
ifconfig, lan_config, etc.
|
| 9959.5 | | SMURF::GILLUM | Kirt Gillum | Wed May 28 1997 13:05 | 22 |
|
Re: .3
The DE500-XA is probably on a different PCI bus than the DE500-AA.
The reason we increase the the FIFO size is due to transmit underruns.
This means that the PCI bus is so busy that the card can't get data
fast enough (hence the change in the FIFO setting).
Updating the firmware on the system might not be a bad idea. I vaguely
remember a fix related to programming the PCI bridge to not allow
unlimited bursts from any PCI source (which is typically the reason why
the DE500's experience underruns).
As always, this is not official support. If you need resolution, do
what you need for resolution (IPMT, etc.).
The driver sounds like it's behaving normally. As I said in .4, I
can't vouch for higher layer software.
Kirt
|
| 9959.6 | Very reproduceable and not load related! | CSC32::A_LICAUSE | | Fri May 30 1997 11:02 | 31 |
| I have spoken at length to the second customer mentioned in .3
He is testing this performance by using two Alpha 1000's both running to
the same Cisco Catalyst 5 hub...both configure to run at 100Mbps
1/2duplex. One has a DE500-aa and the other the xa model. Both
systems are running v4.0b with 128M RAM.
He is doing an rcp of the vmunix image as a test. Neither system is
doing any other task and neither system is busy beyond the rcp.
When then transfer from the AA to the XA, no problem, but when they
transfer from the XA to the AA, the FIFO adjustment takes between 55
and 90 seconds to complete. During this time the system is locked to
anyt additional user activity.
The FIFO adjusts once then is fine unless a long period of inactivity
takes place. As a test, they left the system sit over night and then
ran the rcp again 1st thing. Same adjustment same delay.
Why is it that we don't see this with the AA?
This should be easy enough to reproduce in DEC engineering!
Does the XA have a long product life or will it be phased out shortly?
If it will be with us for a while it would probably be worth checking
out as I'm sure we will get more complaints from customers as the
presence of 100Mbps hub devices increases!
Al
|