Ghost Solution Suite

I am suffering from incredibly slow, erratic multicasting speed (sometimes it's fine). Seems to be diff't machines (with diff't NIC's) at diff't times of the day, using floppy boot, CD boot and RIS Ghost.

It has become worse since moving Ghost 8.0 onto a dedicated Win2003 sp1 server (high spec) So what actually will affect the speed? How far into the network do I have to investigate (ie. will a crap switch in a remote room affect the speed elsewhere?). I look at server processor and network activity while 'slowly' ghosting and it's all below 10%.

My office network points (where I ghost often) plug into a new 10\100\1000 switch (have tried a diff't make and model of switch) with just the Ghost server plugged into that switch as well. As it's a flat network this switch is of course connected ultimately to everything else (?).

> How far into the
> network do I have to investigate (ie. will a crap
> switch in a remote room affect the speed elsewhere?).
> I look at server processor and network activity while
> 'slowly' ghosting and it's all below 10%.

Unfortunately, a bad remote switch - even down to a single misconfigured duplex setting on a single switch port - can indeed negatively impact the whole session.

The basic way multicasting in Ghost works is that the system tries to determine a transmission rate for the entire multicast session that every client in it can live with. This isn't just about network performance; it goes all the way through to the rate that the Ghost clients can retire the incoming data to their disks (what we'd normally call flow control).

Unfortunately a particularly problematic machine or link can wind up dragging everyone else down. If you're using the GhostCast server manually, there are logging options in the advanced settings dialogs that you can turn out to get a trace of exactly what the multicast protocol is doing.

If you do a packet trace, in general the bulk of the traffic coming back to acknowledge the outgoing image data should be from a single client - that's a "leader" for the whole group chosen by the server, and over time what should happen is that the slowest machine in the group will get chosen as the leader.

Provided that everything in the protocol is working well, the clients chosen as the leader are usually the ones worth investigating. That's not always true; in some cases things get bad enough that the server ends up picking a master client on a fairly arbitrary basis. But in general, the master clients get to be the slowest ones.

I don't know if this will help the multicasting speed, but may reduce you overal network traffic.

Are all of your computers (servers and clients) on the same subnet?
If so you might want to change you TTL setting in the Ghostcast server application.
Start up GhostCast manually, File, Options, Multicast Scope TTL, set it to 1
This will tell the routers not to broadcast past the router.
This will reduce you broadcast traffic to other subnets

Ok, I'll Bite

How can you find out who the leader is?
Can this be determined in GSS?
Or do I need other hardware/software?

> How can you find out who the leader is?

In the GhostCast server's option dialog is a logging panel; you can set various levels of logging there. The output is just a text file, although at the most detailed logging level it can get pretty big.

At a sufficiently high logging level, the log should contain specific log messages describing when the server is switching clients.

At the Ghost client there is a similar command-line option that can produce the same logging information (but from the client's point of view). I'm at home rather than the office so I can't tell you exactly what the specific switch is, but the options available are exactly the same ones you can set through the GhostCast GUI.

> Or do I need other hardware/software?

You don't exactly need it, but it can help in some situations. The built-in logging captures what the protocol code at one of the endpoints thinks is going on; thanks to the presence of things like firewalls, what actually goes out on the wire can sometimes be different, and in addition it can let you capture and inspect low-level network control traffic (such as ICMP, IGMP and DHCP packets) that operate at a level below what Windows applications see.

I'm personally quite fond of the packet sniffing tool Ethereal (see http://www.ethereal.com for Windows downloads); internally we have a plugin for Ethereal that understands Ghost's multicast packet format so it can give a similar kind of breakdown of the packets to the one you can see in the built-in logging.

It does take a fair bit of practice to use a tool like Ethereal effectively and understand all the detail it can show you, so I would start with the built-in logging in GhostCast to start.

Not sure if this will be noticed, as the original posts are old, but we recently upgraded to GSS 2.5 from v. 2.0 and we're encountering the speed issues (slowness) as well. We're using PCDOS, and often using the UNDI driver (which worked fine with our machine types in GSS 2.0).

At any rate, I'd like to look at these logs, too, but I can't find the logging options in GCServer or in Console. Any suggestions?

thanks!

In the GhostCast server, look under "Files" "Options", as documented in Chapter 17 of the Implementation Guide (or via the command-line options documented in Chapter 18).

In the Ghost console, the same options are available from the "Advanced Execute" context menu, as documented in Chapter 6 of the Implementation Guide.