This is a strange one. I noticed Sunday Night (CDT) on Blackwood GP i would get disconnected after the race was over. It wasn't every time, but almost every time. Strange things about it was that it was never during the race and not on any other track besides blackwood that night.

Some possibilities that struck me for a cause, before the track had changed that is, was that it was my DSL. It has been raining here for days and I figured it had effected my connection. However, I experienced not a problem with ventrillo when disconnects happened.

After the track had changed I raced 2 or 3 races on FE Gold and never was disconnected. I was even specing for over 30 minutes and never was disconnected during this time either.

Anybody have any ideas or similar experiences to share?

Jay

It's possible that your DSL is partially responsible. Was it a large grid?
Try going to $prefs and selecting a delayed or disabled results screen. Sometimes, for some connections, the burst of extra insim data is too much to handle.

It's a regular for me (regardless of track), and always happens with a sizeable grid. My DSL is quite poor so I put it down to that.

Quote from SamH :

It's possible that your DSL is partially responsible. Was it a large grid?
Try going to $prefs and selecting a delayed or disabled results screen. Sometimes, for some connections, the burst of extra insim data is too much to handle.

Yes. Very large grid. And the next track after everybody left. I will try delayed or disabled results screen.

This really makes the most sense.

Thanks Sam.

jbird - From another North American's POV - Disabling it is best, because even with delayed thre's still that chance of timing out.

Quote from dawesdust_12 :

jbird - From another North American's POV - Disabling it is best, because even with delayed thre's still that chance of timing out.

Noted and thank you for the advice. Could this be because InSim is using UDP to transmit data between the client/server and UPD is non packet checking protocol? The distance between the client and server could disrupt that a bit.

Does LFS have an error log anywhere? or a way to enable a debug/loggin mode to check for errors?

Also, does CTRA remember I changed the $prefs after I leave and rejoin the server at a later time?

Dustin,

May I ask the speed of your internet connection for comparison? Mine is rated at 1.5mbps, but is more like 1.3mbps tested speed. up is around 300kbps.

thanks again.

jay

It remembers the $prefs setting.

I have a 10mbps/1mbps connection.

The actual problem is that Windows (or LFS?) can't deal with the high quantity of button packets sent at once. Gai-Luron did some tests (reference), and by delaying the packets by even 1 ms, the lag caused was eliminated. It would be something to look into (I think) before we bring X2 to the masses.

Very interesting read. Sounds like writing a buffer into their InSim apps helped out.

Speaking of InSim. I've looked around for packet definitions and usage for InSim. I found a few, but they didn't seem to tell me about every packet from InSim. I am probably not looking or searching correctly. Any of you guys know where this information is at specifically?

Quote from jbirdaspec :

Very interesting read. Sounds like writing a buffer into their InSim apps helped out.

Speaking of InSim. I've looked around for packet definitions and usage for InSim. I found a few, but they didn't seem to tell me about every packet from InSim. I am probably not looking or searching correctly. Any of you guys know where this information is at specifically?

So i think i found it in my LFS directory....yeah... didn't bother to look there.