hi
i use the sb client 1.0.2 on linux.
since i upgraded my CPU from a durron 700 to an athlon 2000, the sb client dies quitely after a few hours (~1200 mins).
is my box too fast? jk :p
Printable View
hi
i use the sb client 1.0.2 on linux.
since i upgraded my CPU from a durron 700 to an athlon 2000, the sb client dies quitely after a few hours (~1200 mins).
is my box too fast? jk :p
If you overclocked your box, try clocking it to its rated speed.
I have seen the same thing happen with 1.02... usually after several days.
no, its amds 2ghz but clocked at 1678.947 mhz.
with upgrading i meant i bought a new board and a new cpu
Maybe it is a speed-bug somewhere -- 1.0.2 in linux (Redhat8) never worked for me. Constant crashes. I reverted back to 1.0.0 and it only crashes once every PRP now.
Switch the host name in the sclient.conf file to the IP addy 216.163.34.105. That should fix your 1.0.2 problems with newer linux distros (mandrake 9.0/9.1 also).Quote:
Originally posted by Lagardo
Maybe it is a speed-bug somewhere -- 1.0.2 in linux (Redhat8) never worked for me. Constant crashes. I reverted back to 1.0.0 and it only crashes once every PRP now.
I did that and it made no difference whatsoever. The problem isn't in the DNS resolution, it's in the networking code where a lot of buffers of memory are allocated and never freed (at least that's how it looks like when I run gdb over the remains of the crash -- hard to say much more without access to the source...).
Hmm... the sb client does leave a pile of TCP ports in the CLOSE_WAIT state... maybe that is what is causing the crashing. It would make sense that it runs out of resources and dies.Quote:
Originally posted by Lagardo
I did that and it made no difference whatsoever. The problem isn't in the DNS resolution, it's in the networking code where a lot of buffers of memory are allocated and never freed (at least that's how it looks like when I run gdb over the remains of the crash -- hard to say much more without access to the source...).
Hmm... the sb client does leave a pile of TCP ports in the CLOSE_WAIT state... maybe that is what is causing the crashing. It would make sense that it runs out of resources and dies.Quote:
Originally posted by Lagardo
I did that and it made no difference whatsoever. The problem isn't in the DNS resolution, it's in the networking code where a lot of buffers of memory are allocated and never freed (at least that's how it looks like when I run gdb over the remains of the crash -- hard to say much more without access to the source...).