Optimal performance settings for Spanning Tree Protocol (802.1d) for LAN (gaming) environment
Solution 1:
see http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml
there are a lot of things involved with those timers, some of the things you seem to be concerned about look like premature optimization...
things you should do:
You want your core switch to be the spanning tree root. Set the bridge priority on your core switch to the lowest value. IOS lets you use the special priority 'primrary' which sets it to 8192, so I suppose you could use that. Make sure end user ports have portfast and bdpuguard or whatever Netgear supports for saying "this port should not feed other switches"
maximize hello time to minimize chatter (similar reasons to above)
I would not touch this, it affects everything else. I'm pretty sure increasing the hello time increases the time it takes to detect a loop, which is not what you want.
minimize forward delay to start sending actual packets as quickly as possible
This can be helpful if a cable is unplugged, but really it is only going to save you at most 30 seconds or so, which may not be enough to make it worthwhile.
increase path cost on standard ports to avoid connected machines from hijacking traffic
In ciscoland for end user ports you would enable portfast and bdpuguard and all that fun stuff.. end user ports should not be participating in spanning tree in the first place, so the port cost isn't really relevant.
decrease path cost on the link to the core switch to indicate preferable path
Should not need to do this if you make the core the spanning tree root
increase priority on the link to the core (same as above)
Should not need to do this if you make the core the spanning tree root
can these changes have impact on network performance (both lag and transfer speeds)?
No. The only thing they can help with is faster recovery if someone unplugs/reboots a switch. I'm going to assume that if that were to happen, any game in progress is going to get interrupted, so having it come back online after 15 seconds instead of 45 isn't going to make much of a difference to the players.
If you don't have a looped topology(aka redundant layer 2 links) then spanning tree isn't actually doing a whole lot.
Solution 2:
maximize age to avoid rebuilding the spanning tree calculations as much as possible (because the network won't change once it's established)
The optimisations and changes that you're proposing are moot if the topology of the network won't be changing anyway. Spanning-tree is a low impact protocol in the first place. 600 ports / stations isn't that much in the big scheme of things considering spanning-tree.
The beauty of STP is that in the vast majority if cases, it looks after itself - by tinkering with the default, tried and tested defaults, you're risking making things worse for your event -- and may impact on your end users for the relatively short time they're using your network.
decrease path cost on the link to the core switch to indicate preferable path
increase priority on the link to the core (same as above)
It's almost as if you're trying to defeat the purpose of STP in the first place; what if you suddenly have to change the topology of your network (a switch or link goes down, and theres a STP convergence event?), you're going to spend time reconfiguring costs/priorities - something you wouldn't need to do if STP was left alone. By all means, configure a switch as a BDPU root and you won't need to worry about manual path costs.