140.163.4.24*

Moderators: Site Moderators, FAHC Science Team

Post Reply
QuintLeo
Posts: 52
Joined: Sat Jun 17, 2017 5:43 am

140.163.4.24*

Post by QuintLeo »

Failing since late last night or very early this morning (Pacific time) on any attempt to upload a completed workunit to this server.

Generally gets to between 0.7% and 1.5% on the upload, then gives a "transfer failed" message.

I've got somewhere around 100 completed workunits that haven't been able to get uploaded due to this issue.

It would appear from here that the server in question has suffered a hard drive failure, or it has a hard drive that has filled up.
QuintLeo
Posts: 52
Joined: Sat Jun 17, 2017 5:43 am

Re: WS 140.163.4.242 Failed to send results

Post by QuintLeo »

140.163.4.243 *.242 *.245 are all failing to accept uploads now, I have a TON of "completed" work units that keep trying to upload to those servers, but fail within the first 2% of the upload.
.243 per the logs appears to have been down for over 2 weeks now, the others CLAIM to be up but act like they have hard drives that are too full to accept uploads, and have been this way for a day and a half (more or less) now.
Joe_H
Site Admin
Posts: 7857
Joined: Tue Apr 21, 2009 4:41 pm
Hardware configuration: Mac Pro 2.8 quad 12 GB smp4
MacBook Pro 2.9 i7 8 GB smp2
Location: W. MA

Re: 140.163.4.245

Post by Joe_H »

I have checked the logs for this server, it has been receiving and entering into the stats database an average of about 200 WU's per hour. So it does not appear to be a problem with disk space or a drive failure as you have guessed.

If your transfer failed messages include something like the following:
Failed to send results to work server: 10002: Received short response, expected 512 bytes, got 0
that points to a network issue between your systems and the WS. Something is either blocking http transfer using an app other than a "known browser", or the acknowledgement packets for the transfers are not returning to your systems. They could be filtered or dropped by settings on network equipment that consider them redundant.
Image

iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
Joe_H
Site Admin
Posts: 7857
Joined: Tue Apr 21, 2009 4:41 pm
Hardware configuration: Mac Pro 2.8 quad 12 GB smp4
MacBook Pro 2.9 i7 8 GB smp2
Location: W. MA

Re: 140.163.4.245

Post by Joe_H »

The logs for the other servers in this group also show they are receiving WU's from other folders during this time period, the same issue probably exists between your systems and these servers.
Image

iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
QuintLeo
Posts: 52
Joined: Sat Jun 17, 2017 5:43 am

Re: 140.163.4.245

Post by QuintLeo »

It's odd that it was working prior to the last day and change, then suddenly stopped when I have made no changes on my end.
Joe_H
Site Admin
Posts: 7857
Joined: Tue Apr 21, 2009 4:41 pm
Hardware configuration: Mac Pro 2.8 quad 12 GB smp4
MacBook Pro 2.9 i7 8 GB smp2
Location: W. MA

Re: 140.163.4.245

Post by Joe_H »

it could be due to a change by your ISP, your router might need to be reset, or some anti-malware recently was updated. There are a number of other possibilities. But so far this does not appear to be a general problem with these servers.

It could even be due to some hardware on the network failing. As an example, last week into the beginning of this week I was having similar upload problems. Eventually I traced it down to a failing DSL filter on my connection. It was causing a large number of retransmits and packet loss.
Image

iMac 2.8 i7 12 GB smp8, Mac Pro 2.8 quad 12 GB smp6
MacBook Pro 2.9 i7 8 GB smp3
QuintLeo
Posts: 52
Joined: Sat Jun 17, 2017 5:43 am

Re: 140.163.4.245

Post by QuintLeo »

Did a lot more testing - looks like it's a connection loss issue between windstream.net and however those F@H servers connect to the Internet, as I can traceroute that far then it goes bad - could be an issue inside windstream.net but no way for me to tell as I get NOTHING back past a given point.
Traceroute to the assignment server works fine.

*sigh*

It's REALLY odd though, as the transfers were starting, getting a seemingly random % INTO the transfer, then just "transfer failed" with no indication of WHY the transfer failed and was aborted.
bruce
Posts: 20910
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: 140.163.4.245

Post by bruce »

Something like this?
8 90 ms 83 ms 84 ms ae-0.a02.asbnva02.us.bb.gin.ntt.net [129.250.5.190]
9 82 ms 84 ms 83 ms ae-0.windstream.asbnva02.us.bb.gin.ntt.net [129.250.207.22]
10 85 ms 85 ms 82 ms ae13-0.cr02.asbn01-va.us.windstream.net [40.128.10.173]
11 89 ms 95 ms 91 ms be1.agr04.nwrk01-nj.us.windstream.net [40.128.248.7]
12 87 ms 92 ms 90 ms xe1-0-0-0.pe07.nwrk01-nj.us.windstream.net [40.128.249.134]
13 90 ms 93 ms 89 ms 74.8.57.6
14 * * * Request timed out.

The only way I know of to deal with a problem like that is to report it to your ISP who should pass it up the line to whomever administers 74.8.57.6 for windstream.

but other approaches rarely work but you can also try contacting windstream.
Post Reply