Wierd Errror, 'TooSmall' Occuring On Astraweb/US-SSL

[Beck38]

I have a ticket in on this, but in well over 20+ years of being on Usenet (on more servers than I can count), I've never seen this type of error:

441 437 Rejected 3 000001 TooSmall

Like everyone else (I'll 'assume'), I get my share of one connection or another (I usually run 8 SSL connections) were the 'front end' processor gets either 'confused' or whatever ('Socket Connection Reset'), usually get those on average once an hour (although sometimes it runs for several hours with no 'reboots' on a connection.

But this is the first time I've ever seen a 'TooSmall' message. Still running JBinUp 0.90 Beta 8 Build 738, going on what, over two years now.

Like I said, got a ticket in at Astra asking 'what kind of error is this?' but... had Mr. Google look for a reference, and the only real return was way back in 2006, where folks are discussing it as happening 'all the time' (again, I've never seen it in 20+ years!)

Who knows. These arn't 'small' files by any means.


UPDATE:

About 10 minutes after I posted this (and my query to Astraweb) my ISP went down hard. HARD.

It's possible that they had something going on in their plant, it's been 'shaky' the last couple weeks (at least 2 'scheduled' repair outages in the middle of the night that didn't seem to affect me).

We shall see.

[Hole69]

1) Dump J-bin (beta!?) and try Sabnzb+

2) Run Memtest and a HDD diagnostic to rule out local hardware issues

3) Bitch to your ISP, it looks like its their fault.

4) Split 10/10 connections between Astra US and EU. This seems to be the most stable config.

If you have Scocket Connection Refused something is wrong somewhere, you should receive no errors constantly at all.

[Beck38]

Jbinup is an uploading program (the only one I'm aware of that does error checking with the usenet server); Sabnzb is download program.

After things came up, it seemed to stabilize for about 30 minute, then I started getting the errors again. A quick call to the ISP and they still had techs 'out in the field working on it', so I let it run. 'Noise' in the cable plant, so they said.

But no errors of any type for the last 2+ hours, so it may be they found (and fixed) the actual problem, but time will tell.

[mjmacky]

I haven't uploaded in a good long time, but maybe I'll run a test myself to see what's up.

[Beck38]

I'm about 99+% convinced it's my ISP (Cable/Comcast), as they yanked the system (local neiborhood), got it back up really quckly, the errors continued for a while, then faded out.

But it comes and goes. I live right next to an Airport (county/industiral, largest airplane manufacturing plant in the world) and tons of potential for 'ingress' from VHF-AM and high-power HF (aircraft frequencies) which are well known to cause havoc with cabletv frequencies. But except for a couple of outages over the past two years, this has been the only one I could point to very specifically as causing some kind of 'error'.

I gave the Comcast folks my 2cents, hopefully they'll spend some more time tracking down the problem, as it continues intermittantly every 2-3 hours or thereabouts, since they 'thought' they had 'fixed' it yesterday.

I just noticed something in my logs that's VERY interesting.

The error rate (and therefore the 'toosmall' error) jumps way up almost exactly every three hours - like clockwork.

I tracked it from this afternoon to this evening, and yep, every three hours ***ZZZZZAP***

Then it settles back down again, and runs smooth as silk until the next three hour point comes up, and.... you guessed it.

It's really beginning to look like a timing problem with the network, where something is slowly getting further and further out of sync, until finally it 'losses it' (large amount of errors ensue), and then it 'snaps back' to being close in sync again. Then slowly drifts out, with little if any errors, until it once again gets far enough out that it can't quite recover the data stream and....

Plop. I really wasn't watching it, or the logs, that closely before, and I'm sure that virtually nobody else is really bothered by it at all (approx. 10 minutes of variable throughput every three hours). But there it is. I passed on the info up the 'chain', and hopefully someone somewhere in Comcast will see it and a lightbulb will go off over their head.

[Beck38]

Well, scratch what I said before (!). Took all day yesterday, but confirmed that all the transmission links (from my location/ISP through right to the last 'hop' going into Astraweb/US) are not the problem. It's either the last piece of fiber (Cogentco) going into Astraweb/US or the front end to the Astraweb plant itself.

We shall see if Astra can figure this out, or if it's the fiber provider, they 'wash their hands' or take some pro-active action. Again, it looks from my end to be timing slips that occur some 190minutes apart.

[nntpjunkie]

That is monumentally strange but kind of cool at the same time....maybe your bits are in a time warp...

[Beck38]

In the transmission world, it's not strange at all, except that someone (or more) somewhere simply isn't responding to the alarms or error logs that are staring them in the face. Astraweb should be hip deep in error logs from their front end plant, clearly showing that every 190 minutes they are generating a slew of block repeats. That would lead them into looking at the border router logs, which would lead them to the transmission system port those logs are pointing to. But the transmission company (tracert says Cogentco) is ignoring system alarms which would, again, lead them to look at the logs in their equipment right off.

Unless, of course, they are simply ignoring them.

[mjmacky]

Alright Beck, I see you've already figured out it was not your ISP. I'm having the exact same issue, and I'm most likely using a much older the exact same version of jbinup than as you. Also tested on the US server, non-SSL. I'm only using 4 connections.

[Beck38]

Yep. If you do a tracert to the Astraweb/US ports, the last hop should be over Cogentco (a large fiber outfit in Silicon Valley), and as I said this looks very, VERY, suspiciously like framing slips on a SONET fiber link, if not something else going on with the 'front-end' at Astraweb. But I'll bet it's the fiber link.

Astraweb hasn't responded to my trouble ticket from 2 days ago when they said that 'intermittent' problems couldn't be solved. This isn't 'intermittent', it's very regular. Like clockwork. Check your stuff. Check the vendor's supplying you. Do your job.

I might add, that using JBinUp means that all those errors are 'fixed' by utilizing that uploader; if someone is still using PowerPost or one of it's variants, this problem will be generating a ton of (hopefully with pars correctable) problems, but that is depended on how fast the upload is running. I run 'pretty fast' (it's almost as fast as the fastest available at my house, quite a bit slower than a couple miles down the road but them's the breaks).

The folks at Astraweb may (MAY) feel that keeping an eye on the fiber feeds into their facility is 'not their job'. If a backhoe was perched outside their building when they came to work in the morning, digging away in their 'front yard', they wouldn't pay it any nevermind. When the links went out a couple hours later, they couldn't/wouldn't 'connect the dots'.

As many have noted in the past with Astraweb, 'what a way to run a railroad'. But I'm not going to say that any other provider is any better (nzbmatrix, located outside of Toronto, CA, has had several outages due to 'backhoe fades' and their hosting facility doesn't have diverse routes on it's fiber feeds).

Here's hoping that maybe someone will notice that alarm (that's been silenced) blinking away at some point.

FYI, the ISP/Comcast part of this problem that got me off the track of 'tracking it down' a bit, was caused by Comcast deciding to upgrade the firmware in my cablemodem. In talking to them this last Friday, they could 'upgrade' the firmware, but upon finding out 'after the fact' that the vendor (and the equipment) couldn't 'downgrade' it's firmware 'over the network'. Okay, yet more software folks who can't program their way out the of proverbial 'wet paper bag'. So, they said they saw problems with that upgrade, and had to come in and physically do it.

Well, it didn't work exactly, the visiting guy saw some other problems, and ended up swapping the entire unit out, which caused yet more problems. A couple hours later, those looked fixed, and he shook his head and said 'try it out', and away things went. Looks good from my standpoint, and I'm trying some heavy/fast inbound/download transfers today, which is so far working 100%, so it looks okay. Cross my fingers.