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