QuoteI once read that Nasdaq programs extraneous hops into their routers, so that market-makers at Montgomery in CA can operate on a level playing field with Madoff in NY.I really doubt that this is true.

I heard a story, and I don't know if it is an urban myth type, but here it is: on one of the European electronic option platforms, one dealer placed his systems inside the same computer room as the exchange. The other firms were missing out on nearly all of the deals and could not figure out why. It turned out that the response time was so much faster on the strategically placed system that no one else stood a chance.Regarding your other question about neural network chip sets, I wrote software about 10 years ago for a specialized chip that Intel built (briefly). The conclusion that the community appeared to come to regarding neural nets and hardware was to use software. Namely, develop chips that could perform arithmetic (or linear algebra) extremely quickly and write the software in a more generic fashion. I don't have direct experience with the full chip development cycle, but I did take a class in chip design where we designed a pretty powerful DSP. My guess is that the thinking remains using general purpose type processors (although that might not be an x86 with Excel or C code). Designing new chips is not trivial and you don't want to get anywhere near testing out the first one off the line. Plus, even if you had the chip, you would need all sorts of "regular" components to handle display, communication, etc.

Eurex sayed that at all the connection points like NY,London or Frankfurt..... have the same delay.My personal exp is that the biggest problem for EUREX connectivity is most the MISS, the delayfor network ist most likely not above 150 ms it can be low as 20 ms if you are in Frankfurt.If some one realy is intrested we can setup some tests in the EUREX Simulation to see if thereis any significant delays for different locations, but this will every time include the MISS, so it is very difficultto say if the delay is because of a slow MISS System or just the network delay.

It may be (sort of) true.It is not just the number of hops, but also a swathe of things like bandwidth.I work for an ECN, and we observe considerably different packet latency from the firms we link up to, even when their connection is identical as far as our equipment is concerned.In no particular order:ECN data flows contain a lot of stuff other than price and trade packets.Few, if any systems give priority to "trade" requests over price updates at the packet level, and it would be non-trivial to get banks internal networks to prioritise packets within each ECN protocol.There may be far more hops and delay in navigating through bank networks than you might think/hope. This includes internal routers, switches and firewalls, the last can add considerably to latency, since it is often handling multiple feeds.These latencies are not constant, indeed I've used network stats to generate "really" random numbers, as opposed to algorithmic pseudo-random ones.At the risk of stating the obvious, network cards are serial devices. To be sure they are serial at 10 or 100 Mhz, but they are only doing one thing at a time(sometimes not even that In any case they are usually throttled by the network infrastructure boys, who've long learned not to mention this to traders. To tell if this is you, ask your IT director a golf trivia question, if he gets it right, you're throttled.Many client software packages are effecitvely single threaded, thus in a busy market with high tick frequency of price updates may impact the client ability to send trade orders. There is no win-win strategy here, even with free threaded applications, since you have to decide whether a) to let the trader act upon old data, or b) make him wait until all updates are processed. Basic computability tells you that you can only do (b)when the input queue on the workstation is empty. On top of this the PC needs low latency, highly technical issue, but as a hint, havinggames run "in the background" can affect your bottom line. At no time can a trader be said to be seeing the true state of the market. It may be the true state, but basic relativity will tell you that you can't know it is.This matters. yes really it does. The quote you click on, or call an API to lift doesn't exist on the workstation, but on a server far away.I define "far" here as 50 millseconds or above, this being the lower bound for ECNs assuming you have a good network like Barclays. No I'm not going to say for which firm 50% is added to that figure in simply getting out of their building, but if you care ask the golf questions.In ECN land we use the term "sperm and egg" for trade hitting. This is the discipline that any quote may only be hit once regardless of numbers of attempts. this isn't as easy as it sounds, but we get there in the end.Dominiconnor

Dominic, can you clarify what you're saying a bit please?I think the orirginal thesis by MP was that ECN adjusts it's network infrastructure setup to compensate for the lag "remote" clients have to give them a fair chance. I read to mean it that it "slows down" the clients that have better connection. This would be quite an odd thing to do (and to advertise), in my humble unqualified opinion.From your post I understood that ECN observes different packet latency, that's quite reasonable. You don't really imply that ECN, seening this different latency, adjusts the parameters of it's own network for different clients, do you?

Which bit would you like clarified, ? This is a large % of my job, so I don't want to bore people senseless with the trivia that is my life We have been asked by clients to adjust latency to compensate for things like the fact they are further away.We can do this. It is actually rather hard though, and we don't do it in any production system.The sort of industrial strength routers we use allow for preferential priority for different packets based upon source, destination, and to anextent content. However the effects are essentially impossble to make deterministic. I would feel very uncomfortable about doing this, since as middlemen we have a reputation to protect.However, there are some grey areas, which if you actually care I can enumerate at a later time.This is of course not how we would do it. I would like to emphasise in case any of our customers are reading this that we don't, but if we wanted to, there are better ways.The first way, which is pathetically easy to code, is a small delay loop in the client software. This could hold packets back for a configurable amount of time, both incomingand outgoing. It would be extraordinarily difficult to detect this, since the latencies we're talking here are threshold for humans, and of course since we're working at the feedlevel, the data would remain consistent. Many ECNs have distribution boxes, taking one feed and "broadcasting" it around the Bank network.These have enough spare MIPS to do all sorts of tricks like this. It may easily be a legitimate "throttling" of the feed. We have one user, who shall remainnameless who hoses data at us as fast as his line will go. fortunately, I had assumed that there would be several such users, so the server complex can cope.If I had erred, we'd probably have to throttle him back.A related way, is actualy a problem we have in that we have (at least) one input stream and an output stream of packets.Which should be the relative priorities of these streams ? What about the the thread that draws the screen ?You can dramtically alter responsiveness and performance that way.Many ECN protocols/servers have bottlenecks where the data is "aimed" at each node in turn. This may be multi-levelled through distribution servers, but the principle holds.The cycle time can be large, certainly a good fraction of a second, and potentially longer. A well written protocol fires the data randomly at next-level hosts. However, it is much easier to just write code that iterates through customers in the same pattern every time.Wannabe first ? DominiConnorI think the orirginal thesis by MP was that ECN adjusts it's network infrastructure setup to compensate for the lag "remote" clients have to give them a fair chance. I read to mean it that it "slows down" the clients that have better connection. This would be quite an odd thing to do (and to advertise), in my humble unqualified opinion.From your post I understood that ECN observes different packet latency, that's quite reasonable. You don't really imply that ECN, seening this different latency, adjusts the parameters of it's own network for different clients, do you?

QuoteWe have been asked by clients to adjust latency to compensate for things like the fact they are further away.We can do this. <...> I would feel very uncomfortable about doing this, since as middlemen we have a reputation to protect.<...>This is of course not how we would do it. I would like to emphasise in case any of our customers are reading this that we don't, but if we wanted to, there are better ways. Dominic, thank you. This clarifies your point. I will probably have more questions on the matter, will send you a private message later, if you don't mind.

Feel free.Dominic