Apparently, the cgs is folding. Think it’s true? I don’t think so:
<div id="maincolumn"><div><a href="index.php?s=clicks&d=xgo&id=540" target="_blank"><img src="ads/540.jpg" alt="AN IDEA WHOSE TIME CAME TOO EARLY"></a></div>
Look at the html code for thecgs.com.. why are they announcing they are closing their doors, in a image instead of a post? 
http://www.thecgs.com/ads/540.jpg
-M
This is a rough failover for 2 switches that have 2 links to the same ISP, and they have a xconnect between both. They run OSPF sending out a default route. Switch A is the master and Switch B is the slave. If Switch A’s primary xconnect dies, switch B will announce a default route via iBGP and OSPF to keep traffic flowing to the net.
Switch A:
interface GigabitEthernet0/1 description Primary Internet Link no switchport ip address 192.168.0.118 255.255.255.252 no ip redirects no ip proxy-arp ! interface GigabitEthernet0/2 description Layer3 To Switch B no switchport ip address 192.168.1.253 255.255.255.252 no ip redirects no ip proxy-arp ip ospf cost 10 ! router ospf 10 log-adjacency-changes auto-cost reference-bandwidth 10000 process-min-time percent 10 traffic-share min across-interfaces redistribute connected metric-type 1 subnets redistribute static metric-type 1 subnets route-map REDIST-STATIC network 192.168.1.252 0.0.0.3 area 0 maximum-paths 8 default-information originate metric 10 metric-type 1 ! router bgp 12345 no synchronization no bgp fast-external-fallover bgp log-neighbor-changes network 10.10.10.0 mask 255.255.255.0 neighbor 192.168.0.117 remote-as 1111 neighbor 192.168.0.117 description Primary Internet Link neighbor 192.168.0.117 version 4 neighbor 192.168.0.117 send-community neighbor 192.168.0.117 prefix-list default in neighbor 192.168.0.117 prefix-list aggregate out neighbor 192.168.1.254 remote-as 12345 neighbor 192.168.1.254 version 4 neighbor 192.168.1.254 next-hop-self no auto-summary !
Switch B (backup xconnect)
interface GigabitEthernet0/1 description Layer3 to Switch A no switchport ip address 192.168.1.254 255.255.255.252 ip ospf cost 10 ! interface GigabitEthernet0/2 no switchport ip address 192.168.2.121 255.255.255.252 ! router ospf 10 log-adjacency-changes auto-cost reference-bandwidth 10000 traffic-share min across-interfaces redistribute connected metric-type 1 subnets network 192.168.1.252 0.0.0.3 area 0 maximum-paths 8 default-information originate metric 300 metric-type 1 ! router bgp 12345 no synchronization no bgp fast-external-fallover bgp log-neighbor-changes network 10.10.10.0 mask 255.255.255.0 neighbor 192.168.2.121 remote-as 1111 neighbor 192.168.2.121 prefix-list default in neighbor 192.168.2.121 prefix-list aggregate out neighbor 192.168.2.121 route-map backup-in in neighbor 192.168.2.121 route-map backup-out out neighbor 192.168.1.253 remote-as 12345 neighbor 192.168.1.253 version 4 neighbor 192.168.1.253 next-hop-self route-map backup-in permit 10 set local-preference 90 ! route-map backup-out permit 10 match ip address prefix-list aggregate set metric 10 ! route-map backup-out permit 20 ! ip prefix-list aggregate seq 5 permit 10.10.10.0/24
Switch B:
BGP routing table entry for 0.0.0.0/0, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 1111 192.168.2.121 from 192.168.2.121 (192.168.5.142) Origin IGP, metric 0, localpref 90, valid, external 1111 192.168.1.253 from 192.168.1.253 (192.168.5.249) Origin IGP, metric 0, localpref 100, valid, internal, best
I will go over a select amount of statements/questions I have been asked in my time in this field, which totals to about 6 years. I challenge anyone to prove otherwise with technical feedback.
-More Traceroute Hops means worse performance/lag/latency.
This is a pretty ridiculous statement that has originated on the CAL forum at some point. The problem is kids seem to think a higher number of “hops”, aka layer3 interfaces on a traceroute indicates bad things. To be honest, there is nothing wrong with having a bunch of layer3 devices on your network. You’d be surprised how many layer2 devices are between you and your target.
-Unable to kill someone indicates the hoster is overloading, (aka bad registry)
This is another, ridiculous statement. On a single core2quad processor, you could technically put as many as 4 to 10 servers on it. As long as the actual load remains somewhat low, the first thing you will notice if a hoster is really overloading is the amount of choke that is generated by the server, because there are no CPU cycles left to process snapshots from the server to client. There are also obsessed kids who keep messing with configuration file settings and think large numbers improve things, but in reality, they can cause more harm. Another issue that nobody really takes into account is the gameserver code itself.
-You suck because when I play, everyone complains about the server.
Online gaming is more competitive than say the NFL. When a team loses on a away server, the team will most likely not maintain any good sportsmanship; therefor they will start to bash the server and complain and complain. Of course, if someone tell me the reg sucks, I tell them to load up an aimbot. If the aimbot can kill people, then the problem isn’t the server, ITS THE USER.
- 64bit OS is better for gameservers
This is mostly untrue. A 64bit OS that is running 32bit binaries is no more efficient than a 32bit OS. However, a 64bit bit OS *and* gameserver code has some benefits, like additional registers to use on the stack, vsyscall based gettimeofday (Linux), and other things. VALVe discontinued 64bit support for no reason.
- High FPS is worse than low FPS.
This is somewhat true, and somewhat not true. The true part is, FPS depends on the clock interrupt frequency, aka HZ. A machine of 1000HZ generates more overhead on interrupts, because interrupts fire off so often. The downside is the amount of bus traffic generated by interrupts, more CPU usage, and some other issues. The pros of it are, more accurate timers (in theory), and more accurate scheduler decisions. Higher FPS has more erroring vs realtime (dips), because of complex math to divide the HZ from the 8254’s PLL. The errors accumulate and you see significant erroring over time.
Another thing to consider is how long a usleep(1000) really sleeps. I’ve measured a usleep(1000) won’t come back for approx 10microseconds.. so a usleep(1000) returns about 8uS, instead of 1uS..
- Unstable FPS means you are overloading.
Hogwash. FPS is estimated.
- Intel is better than AMD
Age old argument. While Intel may have faster chips clock for clock, AMD server chipsets support NUMA and DCA, and have excellent memory latency. Of course, Intel’s new CPUs will have the same stuff, but older AMD opterons have better SMP locking (cheaper), but AMD’s have one problem with the TSCs not being able to be sync’d up, and they *will* drift over time.
- More CPU power gives better framerates.
This is another fictitious statement started by a couple of goofballs. Did you know that, a PIII (Pentium 3) has LOWER syscall latency than a P4? Did you also know that OLDER processors give better overall serverside experiences in regards to latency? Why? Older is faster and newer is “Green”
- Solid state disks ..
Solid state disks have access time in nanoseconds instead of milliseconds, which is great. However, unless you are doing a ton of I/O (which gameservers don’t) every second, then it’s useless.
- Clearing log files / ztmp, etc.
Does nothing to help with ‘performance’. I’m unable to find a valid technical reason behind this. From a quick glance, the engine do NOT read the log files in cstrike/log. It writes to them only. If anything, turn off logging to save a couple of CPU cycles.
The bottom line:
Instead of trying to toss faster hardware at gameservers, just fix the code yourself. Learn how to write kernel code. Fix bugs. Adapt the OS to fit your needs.
Over the past couple of months, I’ve decided to take a different approach to optimizing gameservers. First and foremost, I had to peek at their code.. considering VALVes code has it’s roots from quake code, it was pretty simple to reverse engineer the game to see what functions are doing what.. using olly/ida with visual studio, i was able to reconstruct their sleep code for “Linux” and rewrite it to be more modern. I’ve created a module that is loaded during the game’s init in main() to override those functions and replace them with what I deem optimized.
- memcpy now uses SSE2 registers to save L1 cache.
- time is now serviced by clock_gettime()
Adaptive Sleeping code:
- usleep() is deprecated. We use clock_nanosleep all the way now.
- Adaptive TSC based sleep timers that can be switched on and off. This uses the TSC’s register to get ultra accurate times from the
the processor, and we can schedule a wakeup exactly, with about 200ns of erroring.
- A shared process, /tmp/clock.mmap that is read every few seconds to get time from the OS. This reduces expensive context switching
into the kernel.
About 25 users tested it so far, and everyone LIKES it. There was 2 users who said they couldn’t tell a difference, but I think they said that because I was in the inital beta phases.
Overall this module FIXES busted code. The game is probably 1000x more accurate now (using tv_nsec instead of tv_usec) and it gives you an idea of what really goes on.
At one point, I was for the idea of that forum.
The problem is, you have a couple of companies advertising on there, so if you were to look down on the advertisers, any posts relating to them would get deleted. I posted something about globalfrag (the truth, no bullshit) and the post was deleted. I’m assuming it’s because I either spoke the truth (people say it was un-ethical), or because they complained/threatened to pull their advertising. Truth be told, what I said wasn’t to bash them, it was the truth. They committed fraud. If you lie to someone you owe money to, you are committing fraud. Why should we keep our mouth shut if someone is trying to rob us of money they clearly owe us?
Not only is that site biased, it’s full of kids without business licenses.
As of last night, my account is deleted. I no longer wish to involve myself in a site like that.
FPS measures how accurate a couple of syscalls are.
It all depends on the hardware, and the OS, and the kernel..
Most server processors don’t have power management stuff, therefor, desktop CPUs have too much jitter (SMI interrupt, C3 halt stats) to host high precision applications that
require ultra-accurate nanosleep.
For example, here’s a measurement of usleep wakeup latency on a Linux machine:
0.000018
0.000009
0.000010
0.000015
0.000011
0.000011
0.000012
0.000010
0.000009
That’s a usleep(1000000), the results are never consistant at all. Anyone who says FPS doesn’t do this is full of shit.