For a long time we have been having intermittent network issues, asset converters fail to start for a few seconds, can't connect to dev kits, that sort of thing.

They are transient. You can start the converter, it fails, start it again and it works.

So they weren't considered important enough for me to spend time on it. (I'm a systems coder, lot's for me to do all the time )

A few days ago one of the senior developers was cut off from his devkit for three hours. That was the event that allowed me to spend some time on it.

After a lot of digging I managed to get an error code (0x20). It's unclear if this comes from the devkit or windows, but I'm assuming it's a sharing violation. Immediately I looked at the anti virus setup and made some changes to elliminate this from the investigation.

Didn't solve the problem.

When the same guy lost his devkit again, I sat down with him and noticed that the overclocking tool we use has a "Network optomisation" mode.

I turned it off and his devkit instantly came back. I had a new prime suspect.

After a long argument with the head of IT, I am in the situation that I think this is the culprit, he is positive it can't be. So I want to prove it once and for all.

The trouble is, I don't understand what a "network optomiser" does!

Does it just cash DNS look ups? Change MTU settings? What the hell does it do?

Any body out there worked on one and willing to give me a clue?

the overclocking tool we use has a "Network optomisation" mode

So, first, don't overclock on systems that you actually depend on for real work.
Second, I looked up "Network Optimizer" and it's a synonym for "Snake Oil" in my book.
I have no idea what this particular tool is supposed to do, because there is no such thing as a generic "network optimizer."
You'd have to look up this tool from the particular vendor you're using. Maybe call up their support and ask?

In general, though, if "if installed, it breaks things" and "if removed, it doesn't break things" is the observed data, perhaps the best negotiation tactic with your IT department is to say "OK, so you own solving this problem -- note that it's a P1 blocker for our most senior people."
Then make sure the higher-up muckety-mucks understand who owns the problem and that they're on the clock to solve it. Communications and clarity for all stakeholders is important!

I think this is the culprit, he is positive it can't be. So I want to prove it once and for all. ... The trouble is, I don't understand what a "network optomiser" does!

Is it the cause? Perhaps. Perhaps not. You are rather quick to declare it the absolute source, "to prove it once and for all", especially when you don't even know what it is or how it works.

There are several programs out there, like Realtek's "Lan Optimizer", that enables QoS settings on the card. If that is the system you are fighting over I would tend to agree with your IT guy that a QoS tool (that generally should only do stuff when bandwidth is scarce) is unlikely to be the cause of unreliable handshaking. If the program is something else, it may or may not be the cause.

a QoS tool (that generally should only do stuff when bandwidth is scarce) is unlikely to be the cause of unreliable handshaking

Unless it's written by the lowest bidder on freelancer.com, based on a specification provided by a marketing department.
Not that that would EVER happen for ANY name-brand networking or system tools.
(Actually, it happens all the time, because nobody wants to pay for quality.)

We have to overclock our machines, you wouldn't believe the work they are doing . 8 cores at 2 gig just isn't enough.

I agree it's a bit premature to say IT IS the problem, but empirical data SUGGESTS VERY STRONGLY it is the problem.

I want to move from probability to certainty.

Which is very hard when you don't know what the code is doing.

I have disabled this feature on one guys machine. He used to get this issue at least 5 times a day, he hasn't had it in the two days since I disabled it.

I have it turned on on my machine and have had it once in the same time period.

Hardly rigourous proof, but if it smells like a turd and looks like a turd .....

Or that the driver's just a little old, and the QoS is busted. We had an issue with devkit connectivity, where one machine could talk to a kit after an update, but not another machine. The initial webconfig page would start loading, and then come to a dead halt, and kill the http connection.

That turned out to be related to jumbo packets. The update enabled them for the devkit, and the machine that didn't work had a realtek driver dated ~5 days earlier than the other machine. That caused it to drop any and all jumbo packets, and the second packet the devkit tried sending over was about 20 bytes over the jumbo threshold...