Looks like the Transitioners on Vader have crashed.
Other functions on Vader show green.
Reboot it in the morning, I guess.

---

Donald
Infernal Optimist / Submariner, retired

Looks like the Transitioners on Vader have crashed.
Other functions on Vader show green.
Reboot it in the morning, I guess.

they had the outage yesterday because the guys were out today so could be a while...

---

Looks like the Transitioners on Vader have crashed.
Other functions on Vader show green.
Reboot it in the morning, I guess.

Maybe what's causing the lack of work production?
Plenty to be split, and splitters show green, but even though the ready-to-send buffer is falling steadily & it's well below the usual threshold for pumping out new work, nothing is being split.

---

Grant
Darwin NT

If I remember correctly, split work does not become "ready to send" without the Transitioners.

---

Dave

If I remember correctly, split work does not become "ready to send" without the Transitioners.

That'd do it then.

---

Grant
Darwin NT

Looks like an automated recovery script has started to kick in. Unless one of the out-of-town trips has gone to a completely different timezone, or somebody has insomnia.

The SSP has always confused me, but now I have a good reason to ask about it.

The AP splitters all show not running, but the AP files still show green. What I don't get is what the number in parentheses after each file means. Is it how many channels are left to split in that file, how many are in progress, or how many are done?

The five AP files that don't say "done" all have a (14) after them.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

The SSP has always confused me, but now I have a good reason to ask about it.

The AP splitters all show not running, but the AP files still show green. What I don't get is what the number in parentheses after each file means. Is it how many channels are left to split in that file, how many are in progress, or how many are done?

The five AP files that don't say "done" all have a (14) after them.

There's a legend at the bottom of the tape list:

[dark green]: channels in progress
[light green]: completed channels
[grey]: channels with errors
(each file contains data for 14 channels)

{gripe: why doesn't IMG accept gifs?}

'in progress' means 'started, but not finished' - like a client task waiting to run, they can sometimes stay like that for days. An outrage often seems to interrupt the tapes in progress, and the splitters start on new ones when the project is woken up again. I'm guessing these (14) just need to do a bit of final housekeeping before they're properly finished. The number seems to be the number of channels - out of 14 - which have at least been started - after all, it says (1) as soon as the first channel goes dark green.

The SSP has always confused me, but now I have a good reason to ask about it.

The AP splitters all show not running, but the AP files still show green. What I don't get is what the number in parentheses after each file means. Is it how many channels are left to split in that file, how many are in progress, or how many are done?

The five AP files that don't say "done" all have a (14) after them.

There's a legend at the bottom of the tape list:

[dark green]: channels in progress
[light green]: completed channels
[grey]: channels with errors
(each file contains data for 14 channels)

{gripe: why doesn't IMG accept gifs?}

'in progress' means 'started, but not finished' - like a client task waiting to run, they can sometimes stay like that for days. An outrage often seems to interrupt the tapes in progress, and the splitters start on new ones when the project is woken up again. I'm guessing these (14) just need to do a bit of final housekeeping before they're properly finished. The number seems to be the number of channels - out of 14 - which have at least been started - after all, it says (1) as soon as the first channel goes dark green.

I am certainly aware of the legend, but it doesn't adequately answer the question. "At least started" does seem to fit the evidence, but rather limits the usefulness of it.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Upload problems at present? Everything looks OK but may be a temporary problem?

---

Upload problems at present? Everything looks OK but may be a temporary problem?

Might be regional, I don't see anything obvious on the cricket graphs but my last contact was 20:59:47 UTC.
[Edit] Tja! Things started uploading 5 seconds after my original post! [/Edit]

---

I came home to find a few tasks had failed to upload: they cleared at the first retry attempt. One host also hadn't reported for a while: again, that cleared by itself the next time it tried.

Seems to have been a short-lived network glitch, out of the way now.

Upload problems seem to be intermittent. As suggested, probably local.

---

So this one was interesting.. wu1497896368. It is a B3_P1. When I get those, I throw them at 7-zip to see what their compression level is. If it ends up compressing to under 70% of the original size.. then it has always been 100% blanked. This WU though, compressed to.. 40-something% of the original size, but the stderr shows ZERO blanking. Weeeeird. Maybe those six repetitive pulses were identical and gave LZMA something to compress.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

So this one was interesting.. wu1497896368. It is a B3_P1. When I get those, I throw them at 7-zip to see what their compression level is. If it ends up compressing to under 70% of the original size.. then it has always been 100% blanked. This WU though, compressed to.. 40-something% of the original size, but the stderr shows ZERO blanking. Weeeeird. Maybe those six repetitive pulses were identical and gave LZMA something to compress.

But it's not significantly compressible with zip or gzip or V.42bis modem compression. The difference appears to be because 7-zip normally uses a dictionary size of 1M or larger. Even bzip2 achieves some compression using 900k, but 7-zip in its "Fastest" mode with a 64k dictionary size doesn't.

The AP apps actually only consider extremely short 32 byte (128 samples) sequences when checking whether blanking is needed. That's very different from how a lossless compression algorithm deals with the data, so having the correlation break down sometimes is inevitable.

                                                                   Joe

Noted. I was just pointing out that it was the first time I had seen high compression on a B3_P1 that ended up not only not being 100% blanked, but had zero blanking.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I see that the transitioners have been down again for a while again and the ready to send is dropping quickly.

Cheers.

Hopefully whatever kicked them back to life the last time around will do so again. Even with the recently increased GPU work cache, it won't take long to run out of work once the ready-to-send buffer is all gone.

---

Grant
Darwin NT

Yeah, the transitioners haven't been right for more than a week, in one way or another. Case in point, there are 5 MB splitters, but the status shows 10 channels being split. There are 7 AP splitters, which are shown not running, but the status shows 7 channels in progress of splitting. Whenever it all messed up, a week ago or whenever it was, those channels being split at the time have shown as orphans ever since?

Transitioners are running again as there are now over 350,000 with ready to send and it is splitting at 230.2308 per second. The automatic restart script or whatever it is must have kicked in. In regards to the APs I think you are right Jim. I am sure this will be sorted when you tapes are added

---