Server Performances: AstrawebUS, GiganewsUS, UsenetserverUS

[Beck38]

There is always some kinda **** going on with one Usenet plant or another, just thought that after the last few weeks seeing major problems with one plant or another I'd pack it up into one nice little posting.

AstrawebUS - biggest problem over the last month has been intermittent (and lots of times not so intermittent, as in goes for days at a time) posting slowdowns/halts. I have two ongoing 'tickets' open with them, that are supposed to be being 'worked on', in some cases they 'appear' to have fixed one thing or another (for a day or two) then BAM! off the rails it goes once again. During all this downloading/leeching continues apace with no problems whatsoever, as well as perfect propagation out to their peers. Go figure.

GiganewsUS - Lots of problems getting good connections, mostly due to their wacky non-internet compliant system of having a single URL and doing 'suto-routing' to your 'nearest' Giganews plant. So when your ISP changes or updates their router s/w (or h/w), or some Tier 1 provider (like Level3) runs into problems (or lack of ram in their older Cisco routers which is the latest POS problem) then getting a good solid connection (even on d/l'ing) becomes a problem.

UsenetnewsUS - propagation problems to their peers looks to be a continued problem over the last month plus, as it is taking 36 hours plus for posted articles to 'leave' their plant and show up at just about any other usenet facility. Usenet being a digital bucket brigade, it's analogous to someone taking the bucket and leaving the line for a 'smoke break' lasting x hours. Neat.

Now folks, you may not have ever seen these problems (but myself and others have, take a read over at DSLReports for some of them) but you may notice the 'wobbles' and such here and there. Some of these problems may have been bumped up to a higher level of maintenance (like, spend money on new equipment!) or maybe not. So the problems may be worse or better, depending.

And maybe a lot of it is due to the higher folks taking summer vacation.

[Beck38]

The one plant I didn't mention, simply because it's usually a secondary source, is Blocknews.

Many don't use it for posting, but if they do, they may see tons of problems, not because of the Blocknews plant specifically, but because they utilize as their main outgoing peer Highwinds, probably the worst run Usenet server on the planet.

It runs with the idea, like the bug killer RAID (aka roach motel), things that go in don't come out.

Also, for those leeching from it, will notice that they 'strip' the paths from the articles, so one really can't tell where the message originated or the route it took to get to Blocknews.

[piercerseth]

Also, for those leeching from it, will notice that they 'strip' the paths from the articles, so one really can't tell where the message originated or the route it took to get to Blocknews.

Ugh, if this is indeed the case-well that's utterly retarded. Especially with XTRACE, etc.

[Beck38]

Ugh, if this is indeed the case-well that's utterly retarded. Especially with XTRACE, etc.

They aren't the only ones, UsenetNews does it as well, although it's generally a cold day in Hades that I resort to getting any bits from there, although (obviously) I do have a VERY old block account that will cycle down to zero Bytes sometime around when the end of the known universe occurs.

[heiska]

The one plant I didn't mention, simply because it's usually a secondary source, is Blocknews.

Many don't use it for posting, but if they do, they may see tons of problems, not because of the Blocknews plant specifically, but because they utilize as their main outgoing peer Highwinds, probably the worst run Usenet server on the planet.

It runs with the idea, like the bug killer RAID (aka roach motel), things that go in don't come out.

Also, for those leeching from it, will notice that they 'strip' the paths from the articles, so one really can't tell where the message originated or the route it took to get to Blocknews.

I think most have heard the rumor of Highwinds acquiring Readnews, but just did some tracerouting and it looks like Blocknews is still using the Readnews backend.

[Hypatia]

Astrawbe's EU server sucks completion wise compared to US server. I'm not talking about dmca takedowns, just missing articles here and there. They are all over the place, so to speak.Old files, new files.Hit and miss, really. And it has been for a while now. This is really frustrating tbh. I dunno what problems they seem to be constantly having with the EU server..

Also, from time to time they do have problems with articles missing during upload.(Eu server). I always write them about this and then within days it is fixed. And then in a month , in several months it gets screwed up again.

[Beck38]

With the AstraEU, I occasionally will post something small there and it will 'show up' pretty consistently on AstraUS but will be 'skipped' on either Binsearch or NZBIndex but rarely both, but I think that's a function of where they are getting their 'bits' from (the two Astra plants seem to be pretty well 'locked' together, but I do note that even things posted on AstraUS and reporting as 100% do 'lose' a few bits when checked at AstraEU).

But the problems I had with AstraUS seem to be 'fixed' at least for the present time, in that instead of the path being direct from SF to the plant in SJ, it currently is being routed to LA THEN back to SJ, so it's traveling an extra 600+ miles to get where it's going, but it does get there. Level3 appears to be routing around a problem in SF with, probably, an older Cicso router that may be one of those with a ram deficiency (in the BGP department?) that was/is causing problems, and that routing around it (with the extra 600 miles 'trip') 'cures' the problem with an AstrawebUS destination.

Don't know, except that it's been solid as a rock for the last week during this extra bit of traveling. If it defaults back to a more direct route I'll notice (eventually) and if it starts back having problems I'll really notice pretty quickly.