> hi mikol, collision is nothing to do with the segmentation fault error... > collision is on layer 1 (physical layer) while segmentation fault is on > layer 7 (application layer) of the osi layers... counter-strike version 1.3 > is pretty much stable as far as i know.. > > How do I resolve collisions? > > convert your hub into *switch*.
In my previous workplace, we resolve collisions partly through trial and error. We've been able to stop clients that cause collision by re-crimping the connectors. We've found that some collisions are caused by improperly crimped connectors, the ones where the connector's gold teeth doesn't quite sink into the wire. We were using a cheap (P 700) crimp tool then. It was hard to get a good crimp. We would strike the tool with a hammer for added pressure. Sometimes it did sink the gold teeth quite well, sometimes the gold teeth cut through the wire, but the teeth got skewed. So we bought a pressure-multiplying (is this the right term?) Siemon crimp tool (P 8,000) and re-crimped all connectors. We got good results with this tool. The gold teeth sinks deep and really cuts through the wire. The gold teeth are likewise straight and not skewed. This improved the connections considerably. We've also found that some collision-causing clients have disconnected/faulty strands. The wires are Alcatel UTP CAT5. Some of the wires that we didn't enclosed in PVC or GI pipes got chewed by rats. The UTP wires must have tasted like Pringles to them. We replaced these wires with good ones and insulated them well. This also stopped the collision. Now I know that aside from improper crimping, loose connectors, proximity to power lines, and faulty wiring, the only step left to resolve collisions is to get a switch. Thanks. Before I forget, let me squeeze in this question so I don't pass the blame again to the OSI layers if I run into problems. Is it okay to coil patch cords? (Rick Moen must be laughing right now with my English) We sometimes wind patch cords so it's neat, tidy, and doesn't sag. I've heard that coiling patch cords is bad. The coil becomes a rough electromagnet, causing interference and mucking up the signal inside the patch cord. Is this true? > my main suspect with your problem > is that you had a bad ram in which there is a portion in your ram that > probably at the higher address where the bad memory occured which causes of > segmentation fault everytime counter-strike program is trying to write in > it... to see if my suspect is correct try to replace a temporary good ram > and observe. I enabled memory-parity checking in the BIOS. Will this correctly check the memory for bad addresses? My BIOS once flagged a faulty memory module, and wouldn't proceed with the boot-up process, so I replaced it with a good one and it's been fine ever since. The memory in my Counter-Strike server runs fine and doesn't get flagged by the BIOS. Maybe I should download those lm-sensors from the net to make sure. The server seldom segfaults (<-- sounds like a limerick) and runs fine most of the time. I couldn't predict when it will segfault again. Am I correct in assuming that the server crashes because collisions forces it to recalculate more than usual to compensate for the increased latency of clients and to accurately reconcile clients' hits? This increase in calculations goes way out of hand for the server to handle, so it segfaults. Is this correct? I've also read that the Counter-Strike 1.4 update has a bug fix that makes the server default to 32MB heapsize. Is this bug-fix related to my problem? I don't know what a heapsize is. Please pardon me for my ignorance. I'm just an accountancy graduate, but I'd like to know more. By the way, I run the server with sv_clienttrace variable set to zero. Counter-Strike internet servers sets this value to 1 to compensate for internet-connection lag. I disable sv_clienttrace to prevent the telescope cheat (getting shot even if you're not in the center crosshairs of their telescopic sight), but I have a hunch it adds extra work to the server. With sv_clienttrace set to zero, the server has to send extra packets to confirm that indeed a hit has occurred from the time the bullet left the client to the time it hits another client. The server compensates for the lack of error-resolution with the UDP protocol, and the collisions adds more overhead to the error-resolution process. Is this a correct assumption? I might send my query to Eric Smith of Valve Software later, but I guess the Linux gurus in this mailing list wouldn't mind sharing their most-esteemed expert opinions. Thanks in advance for more helpful explanations. mikol _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
