Ghost Solution Suite

 View Only
  • 1.  Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 08, 2010 09:09 AM
    Hi

    I get low performance (60 MB per minute out from the server) with both GSS 2.0 and GSS 2.5 when using directed broadcast to send an image to the clients. GSS 2.0 used to give good performance a good while back (300+ MB per minute) but then it slowed down (after an software update perhaps? Not sure). I have lived with this problem for some time now.

    Different clients (though all equipped with variants of Attansic L1 ethernet controller), different servers and network adapters have made no difference. Unicast mode gives good transfer rates, but it is unpractical with large numbers of computers.

    The network in question consists of both 1000 Mbps and 100 Mbps switches. Limiting the datarate to a moderate value (eg. 350 MB per minute) does not help. I know there is a good chance that there could be a bad port or some other technical fault that is causing the problem. I'll try to do some proper testing (I have tried disconnecting some parts of the network without success) during the summer when it is quiet.

    Any ideas?






  • 2.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 08, 2010 03:17 PM
    Hello,

    Have you tried using multicast? It does require that multicasting be enabled on routers and switches, but this is definitely the most efficient method to deploy. I would recommend multicast over directed broadcast, if that is an option. 

    Thank you,

    Randy


  • 3.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 08, 2010 05:05 PM
    One very common problem with using low-end switches is related to not supporting multicast, and tends to present as a problem with broadcast: they interact extremely poorly with computers that are powered down to a standby level for wake-on-LAN.

    It is typical for equipment which is in standby to negotiate a port speed with the nearest upstream switch of only 10mbit/s; in concert with a low-end switch this causes problems because the switch will include these ports in broadcast traffic, which of course saturates that link. The consequences of this depend on the particular switch, but it's common for low-end switches to have one low-speed saturated link affect other links which are operating at normal speed (via various mechanisms: some generate collision frames, others run out of internal memory to queue frames, and various other pathologies).

    Enabling multicast (on switches that are capable of it) tends to resolve this naturally, as machines that are powered off don't subscribe to active groups and thus the switches don't send imaging traffic to the slow-speed ports.


  • 4.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 09, 2010 10:42 AM
    Thanks for info Nigel. That is something that I can test.

    Our core switches seem to support the protocols necessary for multicast traffic, but the branch switches do not. Is that enough for multicasting to work with GSS?


  • 5.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 09, 2010 10:57 AM

    Thanks for the info Nigel. That is something that I can test.

    Our core switches seem to support the protocols necessary for multicast traffic, but the branch switches do not. Is that enough for multicasting to work with GSS? Most of the computers are connected to the less able branch switches.



  • 6.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)
    Best Answer

    Posted Apr 09, 2010 04:58 PM
    Any switch that does not support multicast itself will work by instead broadcasting a multicast frame to all its ports; that's normally not a big deal, since for instance it's common to have non-multicast-aware desktop switches (at the level of an office or cubicle) at the leaves of a network served by a multicast-aware core. In that kind of situation, the ability of the core switches to restrict traffic to only the ports which have a client subscribed to the multicast group is still hugely beneficial. But then, most desktop switches degrade reasonably gracefully if they have a low-speed port attached: it's the odd piece of equipment that doesn't behave well which is the challenge!

    Whether enabling multicast will or won't help in your situation or not really depends on the precise location of whatever piece of equipment is slowing things down. Machines in low-power states are just the most common nowadays; old network printers or someone hooking up a dusty old 10Mbit switch somewhere were common culprits in times of yore. To be effective in avoiding problem equipment, your network has to be arranged such that the multicast-aware equipment is able to prune the parts of the network with the problem equipment from receiving the image traffic.

    So, "it depends". That said, multicast is usually best to use if you have it available: even if it doesn't solve speed problems out of the box it can be a useful tool in figuring out where problems lie (which is awfully complex in a multi-tier arrangement) because it still narrows down the scope of the high-load traffic. With multicast you can by testing often narrow down a problem area to the level of a port, whereas with directed broadcast the finest grain you can see is a subnet.

    Ultimately, though, your problem could just as easily turn out to be resolvable by the old Mk.I eyeball watching the status lights on a switch rack, which could lead you to a cube or office with some piece of ancient hardware causing the trouble - looking at performance counters on the core switch is the high-tech equivalent, but sometimes it can be just a matter of spotting one small anomaly. Or not, if this is a general problem with one particular second-tier switch and low-power equipment. Unfortunately since it all tends to result in the same symptom from outside the network ("it's slow"), we can't distinguish these situations.


  • 7.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 12, 2010 11:24 AM

    I checked the port speeds on some of our switches. There were some ports in 10 mbps mode on almost every one. One was a computer in Stand By -mode. A few were computers that were off, but whose network adapter maintained a link at reduced speed. That problem can be fixed with OS driver settings.
     
    I did a small scale multicast test with two computers on the same branch switch. When there was a single 10 mbps port on that switch, speed was approximately 60 MB/minute as it should be with broadcast traffic (the branch switches do not support multicasting). When all other ports were either off or in 100 mbps mode, the transfer rate was over 500 MB/minute.
     
    I’ll do a larger test with 10-20 computers and more switches as soon as I can, but so far things work as you said they should. Your explanation on the way broadcasting and multicasting work with el cheapo switches was very helpful :-)


  • 8.  RE: Slow imagecast when using directed broadcast (GSS 2.0 and 2.5)

    Posted Apr 16, 2010 10:36 AM
    I have now done two larger tests. I made sure that all active ports on the involved branch switches were running at full speed. I used both GSS 2.0 and 2.5. Multicasting worked as it should, and data transfer rates were good.
     
    Thank you very much for your help!