Related to Green Bank ... What did you find with the Slow splitting and deletion of GB data?
It appears the system has got back up to normal speeds.

The returned-per-hour numbers are way down, by about 30,000.
When they get back up to 130k+ then we'll see how well things hold up.

---

Grant
Darwin NT

Qantas flies to Los Angeles with big planes. Maybe some space can be found aboard for our disks, they are not too heavy.
Tullio

. . If there is a problem with the cost of data transfers I wonder how the cost of air freight would be received ...

. . I would expect it would be way less than $100 per terabyte but expensive nonetheless.

Stephen

. .

Hey now be nice to the network people! I was Network + Certified before arthritis relegated me into early retirement! It's not the easiest job! and tough to get into! Besides it's probably "THE DARK WEB" at work! We just need a Jedi to combat it! LOL!

---

Those who fail to remember the past are DOOMED to repeat it!

Related to Green Bank ... What did you find with the Slow splitting and deletion of GB data?
It appears the system has got back up to normal speeds.

We found no obvious reasons why it occurred, nor why it stopped occurring. It could have been related to slow inserts or queries due to the size of the result and workunit tables in the BOINC (mysql) database. I changed some db_purge settings to increase delete speed, but I don't think that solved the problem.

Fingers crossed it doesn't happen again.

---

@SETIEric

. . one of those days :)

Stephen

:)

I hope everything works out as well Eric thanks for the update.

Out of curiosity when everything is working as it should between Greenbank and Berkely are all of the tapes shown on the server status page transferred is one file or are they transferred individually (but all downloaded at the same time)
Thanks in advance. I appreciate you taking the time to answer

---

Related to Green Bank ... What did you find with the Slow splitting and deletion of GB data?
It appears the system has got back up to normal speeds.

We found no obvious reasons why it occurred, nor why it stopped occurring. It could have been related to slow inserts or queries due to the size of the result and workunit tables in the BOINC (mysql) database. I changed some db_purge settings to increase delete speed, but I don't think that solved the problem.

Fingers crossed it doesn't happen again.

AP & MB WU-awaiting-deletion are both climbing sharply. But at this stage they haven't impacted on the splitter output- Received-last-hour is still only around 115k, not the 130k+ it was with the much shorter running GBT WUs.

---

Grant
Darwin NT

So based on the problem with Green Bank, my Dell will not download data but my iMac will. I sthis normal.

Thanks for advising all if us.

Not enough information provided. Post the first 30 lines in the Event Log right after startup to see what BOINC reports.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

Not enough information provided. Post the first 30 lines in the Event Log right after startup to see what BOINC reports.

In Number Crunching, not here...

---

Grant
Darwin NT

I don't see any problems with S.E.T.I. or B.O.I.N.C. on my computer.

Everything appears to be running perfectly.

But, I'm just a volunteer, and not a scientist, so I don't even know what it is that I'm looking at.

---

John Robert Mallernee
Ashley Valley Shadows
Vernal, Utah 84078

I hope everything works out as well Eric thanks for the update.

Out of curiosity when everything is working as it should between Greenbank and Berkely are all of the tapes shown on the server status page transferred is one file or are they transferred individually (but all downloaded at the same time)
Thanks in advance. I appreciate you taking the time to answer

I believe Matt uses multiple parallel rsync connections, one from each of the compute nodes on the Greenbank side. So each file goes over a single connection, but separate files may go over separate connections. Each of the names listed on the status page actually consists of multiple files, each no larger than 4GB.

---

@SETIEric

I hope everything works out as well Eric thanks for the update.

Out of curiosity when everything is working as it should between Greenbank and Berkely are all of the tapes shown on the server status page transferred is one file or are they transferred individually (but all downloaded at the same time)
Thanks in advance. I appreciate you taking the time to answer

I believe Matt uses multiple parallel rsync connections, one from each of the compute nodes on the Greenbank side. So each file goes over a single connection, but separate files may go over separate connections. Each of the names listed on the status page actually consists of multiple files, each no larger than 4GB.

Thank you for the answer. There is lots of compression which would certainly save on bandwidth when transferring files.

---

I hope everything works out as well Eric thanks for the update.

Out of curiosity when everything is working as it should between Greenbank and Berkely are all of the tapes shown on the server status page transferred is one file or are they transferred individually (but all downloaded at the same time)
Thanks in advance. I appreciate you taking the time to answer

I believe Matt uses multiple parallel rsync connections, one from each of the compute nodes on the Greenbank side. So each file goes over a single connection, but separate files may go over separate connections. Each of the names listed on the status page actually consists of multiple files, each no larger than 4GB.

Thank you for the answer. There is lots of compression which would certainly save on bandwidth when transferring files.

Maybe, maybe not. Random cosmic noise won't compress much.

I hope everything works out as well Eric thanks for the update.

Out of curiosity when everything is working as it should between Greenbank and Berkely are all of the tapes shown on the server status page transferred is one file or are they transferred individually (but all downloaded at the same time)
Thanks in advance. I appreciate you taking the time to answer

I believe Matt uses multiple parallel rsync connections, one from each of the compute nodes on the Greenbank side. So each file goes over a single connection, but separate files may go over separate connections. Each of the names listed on the status page actually consists of multiple files, each no larger than 4GB.

Thank you for the answer. There is lots of compression which would certainly save on bandwidth when transferring files.

Maybe, maybe not. Random cosmic noise won't compress much.

Good point Gary. I originally misinterpreted what Eric had said. I misinterpreted that there are multiple files per file listed on the server status page. I read it as each tape was compressed down to no more than 4 GB from its original size of roughly 51/52 GB

---

Related to Green Bank ... What did you find with the Slow splitting and deletion of GB data?
It appears the system has got back up to normal speeds.

We found no obvious reasons why it occurred, nor why it stopped occurring. It could have been related to slow inserts or queries due to the size of the result and workunit tables in the BOINC (mysql) database. I changed some db_purge settings to increase delete speed, but I don't think that solved the problem.

Fingers crossed it doesn't happen again.

Looking at the Haveland graphs, the I/O battle between Results returned-per-hour, WU deletion & Splitter output continues.

---

Grant
Darwin NT

We see a lot of new tapes, was the problem finally fixed?

---

We see a lot of new tapes, was the problem finally fixed?

I suspect it's Matt & Eric burning the weekend midnight oil to keep the data flowing.

---

Grant
Darwin NT

We see a lot of new tapes, was the problem finally fixed?

Message 1917689. ;-)

Cheers.

We see a lot of new tapes, was the problem finally fixed?

Message 1917689. ;-)

Cheers.

That's about the slow splitter/file deletion issue, which is still occurring.

---

Grant
Darwin NT