On 2014-05-27 23:13, Peter Lothberg wrote:
When we where chasing another problem, it was found that packets
"disapear" in the Ethernet fabric at Update, sometimes.
I think you are referring to when we played with transfers and the
performance drops to the floor. That is lost packets because of
interface speed differences. They are not really lost, but there only so
much that can be queued up in the fabric between interfaces with
different speeds.
Maybe Johnny can make a small map of the current topology with all
involved things and the lan-speeds?
That would actually be useful either way, but I'm not sure I can do it
easily.
Johnny
If it was only ONE switch used for all the DECnet speaking things at
Update, it would be simple to make a drawing. And with only one device
per port, I think any resonable switch has enough buffers to make it
work way better.
--P
(I might even find a switch that does it right and send it to Update)
Well, if it was only Update then the obvious other solution would be to just force
everything to use 10 Mb/s. I don't think that other than that, changing the switch
would help much. If a maching is throwing out DECnet packets on a 100Mb/s interface, and
it is received by a machine with a 10Mb/s interface, DECnet will suck because of the way
DECnet handles packet loss and so on. Probably made even worse by really slow physical
machines that don't even read out the packets from the ethernet interface at any good
rates... (Hey, a PDP-11 isn't exactly super fast...)
However, the same problem appears for anyone anywhere when they try to use DECnet locally.
If you run it over my bridge, I actually reshape the traffic to make it ok (that is what
the throttling is about, Bob).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic
trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" -
B. Idol