windows RDP issue

B

bespoke

I have a server co-located near the exchange. Why is it that when my home internet is acting up and transferring slowly (to everything, not just my server) that my orders get sent out much more slowly. If my home internet is fine I can send out about 100 or so orders a second but when it's laggy it's much much less. And if I connect with my cell phone it's even worse. One morning with my cell, all my opening orders didn't fully go out until 5 minutes after the open and that was only 100 or so orders. My quotes are probably lagged too. But why is this?

Even when my home internet is lagging, my remote computer's ping to the quote server is still 1 ms.

It's not just my home computer receiving what the remote computer had completed at a later time, but the time stamps of the orders show that they're getting sent out much slower. Shouldn't my remote computer operate independent of my home computer's connection to it? Maybe I have a misunderstanding how how RDP works.

Hope what I said made sense...
 
Quote from bespoke:

Shouldn't my remote computer operate independent of my home computer's connection to it?
More...
Yes, it does.

Assuming the colo server is not dependent on your RDP connection for order submission then there is some piece of this puzzle that is missing. The speed of the colo server placing orders (or doing anything really) should be independent of your remote connection (RDP) speed/latency.
 
theoretically, it should be indepedent, but in practice it's 100% dependent and will screw you. i've seen the exact same behavior countless times and am currently researching alternative rdp clients. current workaround is to have rdp off when running anything time critical.

i've spent some time debugging this, and i think it may have to do with a bug in how microsoft handles scheduling/priority during intermittent/unstable connections during rdp use. the behavior seems to be, 'when connection is intermittent, devote every last possible resource to rdp to try to establish a connection and ignore every other process at work.' super duper fun when banging a ton of orders out on the open or close. honestly, this one issue and its implications has spurred my team into looking at migrating to a linux environemnt... microsoft scheduler == piece of shit and high-risk for auto-trading.
 
Thanks for the useful info propseeker. That's what I was suspecting but it didn't make sense.

Wow.

So you think it uses extra CPU resources when trying to establish a good connection? I had a CPU fan issue before and it would sometimes reach 80C giving me a warning, usually at the end of the day when there's a large load (slightly overclocked i7). But it would often do this when I logged on via my phone's RDP with 3G, so much so that I could never stay logged in for very long, just enough time to check my positions and make sure things were going smoothly. I've had the fan replaced since and no longer have that issue but it's possibly something to take note of.

From time to time I use Radmin which is a nice remote client. Problem is I can only log into my remote computer with one windows account. But I need to log in with 3 windows accounts for my trading. Also, there's no audio so I'm not alerted by a sound when I enter/exit trades or have some kind of issue.
 
I've seen the exact same behavior as propseeker describes. It should be independent, but it's not. Applications of all types are "throttled" when you have a poor RDP connection, guessing it's a synch issue of whats occurring on the colo vs. what RDP can keep up with in displaying.

Again--solution is to disconnect RDP while the colo server runs, and there will be no issue.

I've seen this across every colo server I have on Server 2003 R1 & R2.

Quote from propseeker:

theoretically, it should be indepedent, but in practice it's 100% dependent and will screw you. i've seen the exact same behavior countless times and am currently researching alternative rdp clients. current workaround is to have rdp off when running anything time critical.

i've spent some time debugging this, and i think it may have to do with a bug in how microsoft handles scheduling/priority during intermittent/unstable connections during rdp use. the behavior seems to be, 'when connection is intermittent, devote every last possible resource to rdp to try to establish a connection and ignore every other process at work.' super duper fun when banging a ton of orders out on the open or close. honestly, this one issue and its implications has spurred my team into looking at migrating to a linux environemnt... microsoft scheduler == piece of shit and high-risk for auto-trading.
More...
 
I've witnessed exactly the same behavior, and it's good to know I'm bot the only one.

I use Rithmic (aka Zenfire) both thru Ninja and their stand-alone front end. In both cases, with 100% repeatibility, if I pull the LAN cable from my currently open RDP client, Rithmic will lose connection for about 20 seconds.

Very frustrating.
 
Quote from propseeker:

theoretically, it should be indepedent, but in practice it's 100% dependent and will screw you. i've seen the exact same behavior countless times and am currently researching alternative rdp clients. current workaround is to have rdp off when running anything time critical.

i've spent some time debugging this, and i think it may have to do with a bug in how microsoft handles scheduling/priority during intermittent/unstable connections during rdp use. the behavior seems to be, 'when connection is intermittent, devote every last possible resource to rdp to try to establish a connection and ignore every other process at work.' super duper fun when banging a ton of orders out on the open or close. honestly, this one issue and its implications has spurred my team into looking at migrating to a linux environemnt... microsoft scheduler == piece of shit and high-risk for auto-trading.
More...

Well said. I agree, if your trading software is platform independent get off of Windows it is simply not robust enough to be counted on for anything above a personal or corporate workstation.
 
Looks like I'll just write myself a simple server-client app for my comp and phone that will run in the remote's background and give me a live update of positions, and I'll just log into the server if something goes awry.

It'll be for sterling and android phones. If anyone is interested in a copy I'll pass it along when I'm done writing it.

Thanks for the info guys.
 
You must log in or register to reply here.
Back
Top