Queue Status

Queue Status answers one question: is JudoNet keeping up?

JudoNet does not do its work the instant a packet arrives. Packets go into queues and are dealt with in batches, which is what lets it cope with several mats reporting at once.

The page updates itself every five seconds. You do not need to reload it — leave it open on a second screen during a session and it stays current. If it cannot reach JudoNet it says so at the top, rather than leaving old numbers on screen looking live.

The page is divided into blocks, and they are of two kinds:

Waiting now

Small numbers that keep changing are healthy. During a busy session the queues fill and empty constantly; a number of a few dozen that drops again a second later is JudoNet working normally. No marker appears until a queue passes 100, which is also the point at which JudoNet raises an alert of its own.

A number that only grows is the warning sign. It means work is arriving faster than JudoNet can clear it, and something is wrong underneath — see when storage falls behind.

UDP sending — by channel

One row for each thing JudoNet broadcasts to on the local network.

The columns:

Counts are packets, not network sends. A packet broadcast to three interfaces counts once here. The per-interface table below is where individual sends are counted.

What each column tells you when it moves

Failed is a network problem. The packet reached the sending stage and every enabled interface refused it.

No interface is a settings problem, not a network one — nothing was switched on to send through. This is the counter that finally makes an old trap visible: previously the graphics queue would empty normally and read zero while nothing actually left the PC. Now that case has its own number.

Superseded is normal, and will be non-zero at every competition. It means a newer packet for the same mat arrived before the previous one had been sent, so the older one was dropped in favour of the newer. It does not mean sending is falling behind.

The scoreboard sends on a fixed rhythm and again whenever the board changes. A contest timer rolling 03:27 to 03:26 is a change, so when a roll lands beside a rhythm tick, two packets for that mat arrive microseconds apart and the newer one is kept. Two unsynchronised clocks coinciding is all this counter records.

Nothing is lost. Only the UDP sending queue replaces packets. Local storage is a separate sink that does not coalesce, so both packets of a pair are still written — the stored record of the competition is complete either way.

The older packet is dropped rather than sent late because these channels carry what is happening now, and sending a stale scoreboard state is worse than sending nothing.

Measured over an eight-mat hour: 56 replacements against 30,664 packets on each channel — 0.17% on the graphics channel, and fewer on the recorder. Every displaced packet had been waiting between 0.3 and 1.3 ms, nowhere near the fifth of a second that a sender actually falling behind would show.

UDP sending — by network interface

The same sending, counted per network adapter, so one adapter failing can be told apart from all of them failing.

These are individual sends, so the totals here are naturally larger than the channel totals — one packet going to three interfaces adds three.

One interface showing errors while others do not points at that adapter: unplugged, disabled in Windows, or on a network that has gone away. All of them showing errors at once points at something broader.

Sent to the platform

Three blocks of counters for data going to the online platform. They only ever climb, so a large number means JudoNet has been busy, not that anything is wrong.

Realtime packets — the live stream of what the scoreboards are showing.

Data packets — the bulk upload of stored packets.

Contest times — the start and end time of each contest.

Reading the counters

Within each block the successes are listed first and the failures last, so the bottom of each block is where to look.

A red dot appears beside any failure count above zero. That is the thing to look for — you do not have to read the numbers themselves.

An amber dot means something that needs attention but is not a failure: a queue that has grown past 100, or the No interface column above. No dot ever appears beside Superseded — it is normal at any value, and JudoNet renders it as a plain number.

A failure count that rose earlier and has since stopped rising is history, not a live problem — the dot stays because the total is still above zero. To tell the difference, watch whether the number is still climbing, and check Alerts and Errors, which reports the reason and clears when the problem resolves.

Resetting the counters

Reset counters sets every total on this page back to zero. It is the practical way to start a competition from a clean slate, so that any number appearing afterwards belongs to this session rather than to testing you did that morning.

• The button appears only when you are signed in, and asks for confirmation.
• It clears the totals only. Queued work is untouched and still gets sent — resetting does not throw anything away.
• The accumulated totals cannot be recovered afterwards.

When storage falls behind

JudoNet raises an alert by itself once more than 100 packets are waiting in either the file queue or the database queue. You will see it on Alerts and Errors as well as here.

What to check, in order:

1. Free disk space on the JudoNet PC. This is the most common cause by far.
2. Whether the database was cleared before this competition — see backing up and clearing.
3. Antivirus scanning C:\JudoNet. Real-time scanning of a folder being written to constantly slows it dramatically; excluding the folder is a normal thing to ask for.

If it keeps growing

JudoNet does not let a queue grow without limit — that would eventually exhaust the PC's memory and take packet reception down with it, which is worse than the original problem. Instead the queue has a ceiling. Once it is reached, the oldest packets are dropped to make room for newer ones, counted in the two dropped rows, and an alert is raised.

This is a deliberate last resort: bounded, visible loss instead of an unbounded failure. It does mean that by the time those rows are moving, data from this competition has already been lost.

What this page does not show

The page now covers all three UDP broadcasts and both storage queues. What it still cannot tell you is whether anything is listening at the other end.

A packet counted as Sent left this PC successfully. It does not confirm CG - JudoGraphics or a FairReplay recorder received it — UDP broadcasting gets no acknowledgement back.

To check the other end, use:

• The FairReplay Recorders section of Live data — a red status means inputs are not recording.
• Alerts and Errors — connection problems are reported there.
• The UDP log, C:\JudoNet\logs\UdpSenderService\udp-<date>.log, which records the broadcasts themselves.