Gigabit Switch

[Mark Hahn]

> > 1. suppose you could attach a QOS/TOS tag to small packets, and 
> > have the switch give them preferential treatment.  for instance,
> > if there's a congested port with a backlog, let small packets 
> > "cut" the queue.
> 
> That means that you actually have a backlog.

if you ever have two nodes sending to one node (eg gather), you will.


> Many switches, especially the 
> cheap ones, have small buffers that can be filled fast, so further (small) 

right, but irrelevant.  the topic is "is there any point to managable
or otherwise fancy switches?"


> Furthermore, by letting packets go out-of-order, you make life harder for 
> the receiver...

TCP is good at dealing with out-of-order.  practically by by definition!


> > 2. the vendor claims that multicast is reliable. 
> 
> See Donald's answers to this very question in this thread:
> 
> http://marc.theaimsgroup.com/?l=linux-net&m=106665132425192&w=2

I remember.  the point is that the switch vendor claimed that full multicast
was not lossy, contradicting Becker's claim.  this vendor specializes in 
large, big-backplane chassis switches, so they might be right.  it may be 
that Don was thinking of a cluster with multiple switches.

I think latency is the real appeal of hw-supported multicast - if you 
want to do a barrier across 256 nodes, do you want a ~8-deep tree of
user-level processes farming out your tinygrams (say, 8x50=400 us), 
or do you want a single 30 us multicast?


> > 3. it would be neat to be able to query performance/load/queueing stats
> > from the switch on a per-port basis.
> 
> That is actually one of the 2 things that I use out of a managed switch... 
> Althought I think the information should be available as SNMP, I use it 
> only when I try to find out if there is some networking problem, which is 
> rarely enough, so I always used the switch CLI or web interface to do it.

which misses the point.  I'd like to be able to let a user find out that 
his node 12 is always bottlenecking the sim because of a problem with his 
domain decomp, for instance.  summary stats are not useful, only per-port
(preferably per-flow, but...)

regards, mark hahn.

_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf