FAQ: How bad is PacBell news?
Jason "Fish" Proctor
John Navas <spamf...@navasgrp.dublin.ca.us> wrote:
> [POSTED TO pbinet.adsl; PLEASE REPLY THERE]
>
> Thanks for the kind words.
>
> My program is working correctly. The problem is that news.pacbell.net
> has become erratic, with wildly varying article availability. But I
> just checked comp.dcom.xdsl again (results posted to this thread), and
> the loss rate was still very high. (Running tests this morning has been
> difficult, because the server has often responded slowly or not at all.)
John's right about the article availability bizarreness. Following a
thread in rec.music.makers.* is very difficult when three days in the
server decides it's going to flush the last 2 days it received. rmms
gets a steady 30 or so per day (I verified this with another server),
and my newsreader says yup, there's 30 or so there, but can pacbell find
them? Nope...
There's definitely different storage strategies being used for different
group hierarchies. pbinet.* comes up quick every time for me, funny
that, but my experience with other hierarchies is extremely varied.
I notice that the server is now hanging again on some alt groups. It was
doing this last week for a while, then they fixed it and things were
actually fast for a few days, now it's back to being buggered again.
Sigh.
Ron Hunsinger
\"Fish\" Proctor" <n...@spam.com> wrote:
> John's right about the article availability bizarreness. Following a
> thread in rec.music.makers.* is very difficult when three days in the
> server decides it's going to flush the last 2 days it received. rmms
> gets a steady 30 or so per day (I verified this with another server),
> and my newsreader says yup, there's 30 or so there, but can pacbell find
> them? Nope...
Try again. The messages are probably really there. The operative rule is:
NEVER believe the pacbell servers when they say something isn't there. Ask
again. You may have to ask several times, but usually it'll eventually come
back and say "Yeah, here's that stuff I told you three times in a row
wasn't here."
-Ron Hunsinger
news.pacbell.net
Every major ISP is able to offer FAST and
RELIABLE email and news - except
PacBell.
PacBell should consider outsourcing mail and news
to a third party like IBM. I'm sure you'd see a
dramatic improvement in the quality of service.
However, it's apparent that PacBell DOESN'T CARE
so wouldn't it be nice to tie the monthly charges
to customer satisfaction and service level agreements.
PacBell believes that consumers don't deserve
much for their monthly charges or they would
have straightened out the myriad of problems they
have which get shoved down our throats week
after week.
I hope the PUC fucking HAMMERS SBC & PacBell
for the shoddy service they provide consumers.
I'm FED UP with crappy news & mail services.
"Jason "Fish" Proctor" <n...@spam.com> wrote in message
news:no-FB218E.11...@nnrp1-w.snfc21.pbi.net...
phonyname
>Let's face it - PBI - SUCKS!!!!!!!!!
>Every major ISP is able to offer FAST and
>RELIABLE email and news - except
>PacBell.
>
>PacBell should consider outsourcing mail and news
>to a third party like IBM. I'm sure you'd see a
>dramatic improvement in the quality of service.
>However, it's apparent that PacBell DOESN'T CARE
>so wouldn't it be nice to tie the monthly charges
>to customer satisfaction and service level agreements.
>PacBell believes that consumers don't deserve
>much for their monthly charges or they would
>have straightened out the myriad of problems they
>have which get shoved down our throats week
>after week.
>
>I hope the PUC fucking HAMMERS SBC & PacBell
>for the shoddy service they provide consumers.
>
>I'm FED UP with crappy news & mail services.
>
Lucky you didn't post this message on the dslreports message forum.
The shill moderator will accuse you of being a troublemaker whose sole
purpose is to discredit PacBell. In fact, there is a current
discussion thread where Paladin claims that news.prodigy.net is not
capped. What a bunch of bullshit.
http://www.dslreports.com/forum/remark,1113227;root=ilec,pcb;mode=flat
Jason "Fish" Proctor
hns...@sirius.com (Ron Hunsinger) wrote:
I tracked most incidents of the symptom you describe down to the alias
"news.pacbell.net" resolving cyclically to 3 different IP numbers. These
are all news servers, but of course PBI being idiots, they don't keep
them in sync, so "retrying" the request to get the article results in
the lookup providing a different IP each time, eventually resulting in
getting the article from the server which advertised its presence in the
first place.
I don't have that problem so much any more since I just picked one of
the IP numbers off the list, and configured my client to just use that.
The problem I'm specifically describing here is one where the news
client looks at the STAT results from the server for a group, and then
from your last read article, calculates how many articles on the server
are unread. Most days this is reliable, today for example two rec.music
groups' STAT results indicated 30 and 40 articles respectively, but
trying to get the article headers (subject etc) resulted in the server
claiming there was nothing there.
Sometimes again I can get articles even when this is happening, by
marking all the articles in the group as unread and starting from the
beginning (might take a while depending on how busy the group is and how
far back PBI can be bothered to keep them). They may show up then, they
may not.
Either way the condition of the PBI servers is a disgrace, I've
complained *many* times, all to no effect. Their non-presence on this
group is very telling.
Has anyone brought in CPUC on this and other PBI-related issues? I've
brought them in a couple of times for phone-related complaints and it
seems to light a fire under people's butts.
But then, I suspect one of the reasons for outsourcing to SBC was so the
internet service wouldn't be accountable to CPUC. Just my cynicism
calling...
ha...@pacbell.net.invalid
snip >>
> Either way the condition of the PBI servers is a disgrace, I've
> complained *many* times, all to no effect. Their non-presence on this
> group is very telling.
>
> Has anyone brought in CPUC on this and other PBI-related issues? I've
> brought them in a couple of times for phone-related complaints and it
> seems to light a fire under people's butts.
Well, open-news now seems to be boned as far as posting goes anyway ...
No one in "tech support" even knows what it is and they steadfastly
refuse to even TRY posting to open-news.pacbell.net ..."use
news.pacbell.
net" - whatta piece of &^%* ... must be *my* setup, yeah ...
A few weeks ago SBC Communications Chairman and CEO Edward Whitacre
went to Congress to get them to "remove the unfair regulatory burden
which is damaging SBC's ability to compete in the emerging broadband
technology market." I think we should write our representatives to
explain that what is *burdening* SBC's ability to compete is the rotten
stinking quality of their lousy service. Rather than "freeing the Bells"
from regulation the House should be investigating why Pacbell Internet
is not in default on its obligations to provide the service *as
described*
in their advertising. John Navas' series of documents and the records
of this group should be subpoenaed by the Comerce Committee considering
this bill. California representatives on the committee are
Anna G Eshoo
Christopher Cox
Jane Hartman
not that any of them care about honesty, customers, or
fraudulent advertising, but maybe at least we can embarrass
the bastards.
Ron Hunsinger
\"Fish\" Proctor" <n...@spam.com> wrote:
> I tracked most incidents of the symptom you describe down to the alias
> "news.pacbell.net" resolving cyclically to 3 different IP numbers. These
> are all news servers, but of course PBI being idiots, they don't keep
> them in sync, so "retrying" the request to get the article results in
> the lookup providing a different IP each time, eventually resulting in
> getting the article from the server which advertised its presence in the
> first place.
Sorry, but that was one of the first things I suspected. I have software
that will tell me what internet connections I have open at any one time
(including the remote IP address), and was able to determine quite quickly
that this was NOT the explanation.
In particular, consider the case where the server reports that a message is
"no longer on the server", perhaps several times in a row, before finally
coming up with the message in question. My newsreader is NOT opening new
connections for each of these attempts. They're all made over the SAME
connection (which is, perforce, to the SAME server), but with different
results.
Let's go back to the case of asking the server for the list of messages
available in a group. In this case, also, I can get back different
responses *from the same server* (even though, in this case, I am quitting
and restarting the application, getting a new connection).
I can tell when the response is going to be short, based on how long it
takes for the answer to come back. It's clearly a timeout issue. What I
see, if I watch the packets going back and forth, is that the newsreader
will make a request to the server, the server will (perhaps) return a few
blocks, a minute or so apart, and then eventually I'll see, after several
minutes, an abbreviated list of messages. (Often, there'll be no blocks
returned at all, in which case I am told that "the newsgroup cannot be
opened, because it contains no unread messages.")
If the messages were truly missing on the server, I'd be told that
immediately. But I never get a short response, or a "no messages" response,
in anything under several minutes. When I finally do get a full list, that
response (usually) comes back relatively quickly.
As tempting as your explanation is, it doesn't jibe with the facts. The
servers are improperly configured, but I haven't seen any indication that
they're out of sync.
-Ron Hunsinger
Jason "Fish" Proctor
> In article <no-FA2B20.18...@nnrp1-w.snfc21.pbi.net>, "Jason
> \"Fish\" Proctor" <n...@spam.com> wrote:
>
> > I tracked most incidents of the symptom you describe down to the alias
> > "news.pacbell.net" resolving cyclically to 3 different IP numbers. These
> > are all news servers, but of course PBI being idiots, they don't keep
> > them in sync, so "retrying" the request to get the article results in
> > the lookup providing a different IP each time, eventually resulting in
> > getting the article from the server which advertised its presence in the
> > first place.
> As tempting as your explanation is, it doesn't jibe with the facts. The
> servers are improperly configured, but I haven't seen any indication that
> they're out of sync.
Well, configuring one IP made my situation a lot better, though of
course it's still far from what I would call "good". If it doesn't make
things better for you, that's too bad.
Today, for example, the news server is once again hanging doing mundane
things like getting articles from my rec and alt groups, and the mail
server has been trying to send a message to support for the last 15
minutes.
those who know me have no need of my name
>John's right about the article availability bizarreness.
that was a damn old article you quoted, but it is still true, as you
note.
>There's definitely different storage strategies being used for different
>group hierarchies.
naturally, it would almost have to be. this is not unusual.
--
okay, have a sig then
those who know me have no need of my name
>I tracked most incidents of the symptom you describe down to the alias
>"news.pacbell.net" resolving cyclically to 3 different IP numbers. These
>are all news servers, but of course PBI being idiots, they don't keep
>them in sync, so "retrying" the request to get the article results in
>the lookup providing a different IP each time, eventually resulting in
>getting the article from the server which advertised its presence in the
>first place.
this would be an unusual newsreader -- usually a single (tcp) session
(and therefore a single server) is used for all communications. only if
you forced a disconnect before re-requesting an article, or if your
reader did that, which would be very unusual, would you potentially
cycle to another server.
>The problem I'm specifically describing here is one where the news
>client looks at the STAT results from the server for a group, and then
>from your last read article, calculates how many articles on the server
>are unread.
if your client "calculates" the number of available articles it is doing
the wrong thing. it can present to you the estimate provided by the
server, but even that is fallible since groups change in real-time.
>Most days this is reliable, today for example two rec.music
>groups' STAT results indicated 30 and 40 articles respectively, but
>trying to get the article headers (subject etc) resulted in the server
>claiming there was nothing there.
usually this is because of one of two things: either overview
generation is running well ahead of article spooling, or due to expiry
for that spool. the later can happen when, for example, two medium
volume newsgroups are allocated to the same spool object with room for n
articles and the "other" group suddenly receives n articles.
>Sometimes again I can get articles even when this is happening, by
>marking all the articles in the group as unread and starting from the
>beginning (might take a while depending on how busy the group is and how
>far back PBI can be bothered to keep them). They may show up then, they
>may not.
this is an indication that overview generation is well ahead of article
spooling. it's also possible that the overview was damaged, and it has
since been rebuilt.
>Either way the condition of the PBI servers is a disgrace, I've
>complained *many* times, all to no effect. Their non-presence on this
>group is very telling.
>
>Has anyone brought in CPUC on this and other PBI-related issues?
doesn't work. the isp isn't a puc regulated entity.
>But then, I suspect one of the reasons for outsourcing to SBC was so the
>internet service wouldn't be accountable to CPUC. Just my cynicism
>calling...
pacbell doesn't "outsource" to sbc, they are sbc, i.e., pbis (pacific
bell internet services) is just a california dba of sbc-is (sbc internet
services).
those who know me have no need of my name
>In particular, consider the case where the server reports that a message is
>"no longer on the server", perhaps several times in a row, before finally
>coming up with the message in question. My newsreader is NOT opening new
>connections for each of these attempts. They're all made over the SAME
>connection (which is, perforce, to the SAME server), but with different
>results.
it is possible that one or more servers are running in chaning mode, in
which case while you did not switch to a different server the server to
which you are connected switched to a different backend server.
those who know me have no need of my name
<xJD47.1$Un2....@news.pacbell.net> divulged:
>Every major ISP is able to offer FAST and
>RELIABLE email and news - except
>PacBell.
i disagree. many others also do a poor job, especially those that now
have a broadband service.
>PacBell should consider outsourcing mail and news
>to a third party like IBM. I'm sure you'd see a
>dramatic improvement in the quality of service.
yes, but it would cost them more than they currently charge so i think
it unlikely to happen.
viewed another way -- they did just that with the prodigy internet deal.
>However, it's apparent that PacBell DOESN'T CARE
>so wouldn't it be nice to tie the monthly charges
>to customer satisfaction and service level agreements.
of course it would be nice, however this service is specifically
provided on an unguaranteed basis, which is reflected in the price.
>I hope the PUC fucking HAMMERS SBC & PacBell
>for the shoddy service they provide consumers.
the puc won't even look into the complaint.
>I'm FED UP with crappy news & mail services.
indeed. you might consider voting with your wallet, rather than just
bitching or hoping that some oversight group will come in an "make it
all better."
i've come to an accomodation, in large part with myself. i realize that
sbc-is does a horrible job of providing most services, so i do them
myself or get them elsewhere. i'm willing to pay $50/mo to get ip
connectivity, provided it's generally reliable and at the existing
speed, which has so far been the case, and to pay for those other
services i deem necessary, e.g., usa.net for this e-mail address.
those who know me have no need of my name
>there is a current discussion thread [on dslreports] where Paladin
>claims that news.prodigy.net is not capped. What a bunch of bullshit.
i found it to be un-capped, up until news.prodigy.net recently began
demanding authentication i cannot provide (i.e., it doesn't accept my
pbis username and password).
Jason "Fish" Proctor
not-a-rea...@usa.net (those who know me have no need of my name)
wrote:
> >There's definitely different storage strategies being used for different
> >group hierarchies.
>
> naturally, it would almost have to be. this is not unusual.
I'm not saying that's a problem in itself. I'm saying that John is not
necessarily wrong in his observations just because other people have
observed different article loss figures in different group hierarchies
than the ones he tested (which is the implication of some of the posts).
If I'm reflating an old thread, stop me. I'm a newbie in the pbinet
hierarchy.
Jason "Fish" Proctor
> this would be an unusual newsreader -- usually a single (tcp) session
> (and therefore a single server) is used for all communications. only if
> you forced a disconnect before re-requesting an article, or if your
> reader did that, which would be very unusual, would you potentially
> cycle to another server.
It's not that unusual if the client is multithreaded (as in this case).
> if your client "calculates" the number of available articles it is doing
> the wrong thing. it can present to you the estimate provided by the
> server, but even that is fallible since groups change in real-time.
The client knows what you've read, the server estimates what's there,
and the client boils the numbers up into an estimate of how many
articles you haven't read. Yeah calculation's probably the wrong word -
but I got it wrong rather than my client. I hope... :-)
(I wrote a news client, I know what you're talking about here)
> usually this is because of one of two things: either overview
> generation is running well ahead of article spooling
Thanks for the theories on the weird server behaviour. Yep, a number of
things can be happening. But the news performance is lightyears worse
than any other news server I've used.
> doesn't work. the isp isn't a puc regulated entity.
CPUC helped me out when they were billing me twice. I had like 5
different people from PBI and SBC calling me to try to sort it out.
Maybe that's because the billing is done by PB??
> pacbell doesn't "outsource" to sbc, they are sbc, i.e., pbis (pacific
> bell internet services) is just a california dba of sbc-is (sbc internet
> services).
Thanks for clearing that up. So PacBell and PBI are not related? Why is
it then that when calling them on the phone, it appears that initial
support is done by PacBell but second line support is SBC?
those who know me have no need of my name
>In article <Hxi67.222$lh.3...@news.pacbell.net>,
> not-a-rea...@usa.net (those who know me have no need of my name)
> wrote:
>> this would be an unusual newsreader
>It's not that unusual if the client is multithreaded (as in this case).
commonly even multi-threaded readers to re-use an existing connection if
that connection is otherwise "idle." still, i'm not trying to say you
cannot have been getting different connections, but that care must be
taken when evaluating the results to ensure that indeed different
servers are being selected.
further there's still a chance that one or more servers are in chaining
mode, in which case using a single connection might result in an
invisible change in back-end servers for each request -- though that is
also unusual.
>But the news performance is lightyears worse than any other news
>server I've used.
indeed. i didn't mean to imply otherwise. sbc-is' servers, all of
them, are the pits.
>> the isp isn't a puc regulated entity.
>
>CPUC helped me out when they were billing me twice. I had like 5
>different people from PBI and SBC calling me to try to sort it out.
>Maybe that's because the billing is done by PB??
yes, because the utility is involved. please do involve the cpuc, if
you can. (though i somewhat fear what kind of shite they might
eventually do it may have a salubrious effect for you in the near term.)
>> pacbell doesn't "outsource" to sbc, they are sbc, i.e., pbis (pacific
>> bell internet services) is just a california dba of sbc-is (sbc internet
>> services).
>
>Thanks for clearing that up. So PacBell and PBI are not related? Why is
>it then that when calling them on the phone, it appears that initial
>support is done by PacBell but second line support is SBC?
oh, they're related, it's just that on paper they are separate
companies.
my understandins is that front-line customer service was being
out-sourced, to a company in texas.
Jason "Fish" Proctor
> commonly even multi-threaded readers to re-use an existing connection if
> that connection is otherwise "idle."
True enough, but the way connections are generally arbitrated among
multiple threads is via a pool. If lookups were done individually as
part of the process for establishing the pool, then each connection
could be to a different news server, and it's not certain that for
successive requests even one thread would be talking to the same news
server for each.
Anyway - configuring 1 IP number instead of a symbolic name made a
dramatic difference to the consistency of stuff the news server reported
and was able to retrieve. YMMV.
Ozzy
Damn - aside from not knowing your name there may be many who would wish
to not know of your existance
> <no-94CCF9.17...@nnrp1-w.snfc21.pbi.net> divulged:
>>In article <Hxi67.222$lh.3...@news.pacbell.net>,
>> not-a-rea...@usa.net (those who know me have no need of my name)
>> wrote:
>
>>> this would be an unusual newsreader
>
>>It's not that unusual if the client is multithreaded (as in this case).
>
> commonly even multi-threaded readers to re-use an existing connection if
> that connection is otherwise "idle." still, i'm not trying to say you
> cannot have been getting different connections, but that care must be
> taken when evaluating the results to ensure that indeed different
> servers are being selected.
>
> further there's still a chance that one or more servers are in chaining
> mode, in which case using a single connection might result in an
> invisible change in back-end servers for each request -- though that is
> also unusual.
>
>>But the news performance is lightyears worse than any other news
>>server I've used.
>
> indeed. i didn't mean to imply otherwise. sbc-is' servers, all of
> them, are the pits.
Verbose bugger.
Mr T
"Hugh Hemington" <hug...@nospam-pacbell.net> wrote:
> Ahem. Pacbell DID outsource its newsgroup some time ago. They don't
> consider newsnet to be a viable medium and resent any user who prods them to
> maintain or enhance it.
>
> Now, as you have probably learned, it is being transferred to Prodigy and
> many of the groups are being eliminated altogether. Does anyone have a good
> recommendation for a third party news server? Obviously its time to
> increase our internet cost and purchase the service separately.
>
> This is, afterall, what Pacbell (SBC et. al.) has been essentially
> pressuring us to do anyway, right?
This is exactly what they've been doing. They have the resources, but
the management has made a decision not to provide anything steller.
They seem to have policies that run their best and brightest out of
their company.
I use Giganews and am very happy with how professionally they run it.
--
Kurt
gjew
I've forgotten how spotty the service is with Pacbell. I had
switchted to AT&T a few years back. But now that I've signed up for
DSL service it brings back the painful memories.
It seems to be difficult to get downloads with their news servers at
times. Slow. Although recently I've been doing OK for some reason.
If AT&T had offered DSL service in my area I would have stayed with
them.