Bit Ceiling (Oct 08 2008)


log in

Advanced search

Message boards : Technical News : Bit Ceiling (Oct 08 2008)

Previous · 1 · 2 · 3 · 4 · Next
Author Message
msattler
Volunteer tester
Avatar
Send message
Joined: 9 Jul 00
Posts: 37311
Credit: 499,472,394
RAC: 510,777
United States
Message 817216 - Posted: 11 Oct 2008, 22:06:25 UTC - in response to Message 817203.

We are paying a tiny fraction for the current 1Gbit than we were paying for the previous 100Mbit connection

If the download/upload server's are on a 1Gbit connection & it's maxing it's self out at around 95mb/s, whats stooping the lab using the other 905mb/s...

Well... I guess you actually mean 905 Mbit/s... ;-)


As described earlier, the cable from the SSL (s@h servers physical location) "down the hill" to the comms rack in another building is just a 100 Mbit/s link. The 1 Gbit/s link is further down the line from there. With tcp and overheads, you can expect 95 Mbit/s max out of that.

And there is insurmountable bureaucracy/costs to upgrade the 100 Mbit/s segment.


Good suggestions I've seen is for a volunteer effort to upgrade the fibre optic nodes or install a microwave link. But is that workable for Berkeley?

Happy crunchin',
Martin

Well......
I just sent off an email to Hyperlink Technologies asking if they would be interested in donating a point to point link to the project.....
My request will probably be filed away in the proverbial round file, but I had to ask........

____________
******************
Crunching Seti, loving all of God's kitties.

I have met a few friends in my life.
Most were cats.

msattler
Volunteer tester
Avatar
Send message
Joined: 9 Jul 00
Posts: 37311
Credit: 499,472,394
RAC: 510,777
United States
Message 817217 - Posted: 11 Oct 2008, 22:08:03 UTC

I just got an automated response from Hyperlink,,,,,,
So at least I know my email got through.
____________
******************
Crunching Seti, loving all of God's kitties.

I have met a few friends in my life.
Most were cats.

Profile KyleFL
Send message
Joined: 20 May 99
Posts: 17
Credit: 2,289,892
RAC: 0
Germany
Message 817227 - Posted: 11 Oct 2008, 22:21:24 UTC

It should be quite easy to setup an WLAN Link from top of the hill to the central campus.
I have done such a link @ with 2 Linksys WAP54G and it was quite easy.
The usable bandwith was ~20MBit, but now with the new Draft-N WLAN Hardware, that should be 5-8times faster.
That additional bandwith does come very cheap and without long installation issues.

Another idea would be to check if it would be possible to use the powerline for network transfers. If seen it work in two houses now -- just plug in the powerline adapter and you get up to 80MBits. I don´t know how the central campus and the lab on the hill are connected -- if the lab uses the same powerlines then the campus. But maybe it would be worth a closer look.


Cu KyleFL


If the whole thing seems impossible, just start with that step that gives the least resistance. If you get an additional hardware-link to central campus, many new paths will open with that possiblity :)
____________

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817282 - Posted: 11 Oct 2008, 23:27:46 UTC - in response to Message 817227.

It should be quite easy to setup an WLAN Link from top of the hill to the central campus.
I have done such a link @ with 2 Linksys WAP54G and it was quite easy.
The usable bandwith was ~20MBit, but now with the new Draft-N WLAN Hardware, that should be 5-8times faster.
That additional bandwith does come very cheap and without long installation issues.

They need 1000 megabits (1 gigabit) and probably more than a mile with good link budgets.

In other words, something better than draft-N.

Some sort of wireless is still probably the better option.

____________

msattler
Volunteer tester
Avatar
Send message
Joined: 9 Jul 00
Posts: 37311
Credit: 499,472,394
RAC: 510,777
United States
Message 817288 - Posted: 11 Oct 2008, 23:40:26 UTC - in response to Message 817282.
Last modified: 11 Oct 2008, 23:41:11 UTC

It should be quite easy to setup an WLAN Link from top of the hill to the central campus.
I have done such a link @ with 2 Linksys WAP54G and it was quite easy.
The usable bandwith was ~20MBit, but now with the new Draft-N WLAN Hardware, that should be 5-8times faster.
That additional bandwith does come very cheap and without long installation issues.

They need 1000 megabits (1 gigabit) and probably more than a mile with good link budgets.

In other words, something better than draft-N.

Some sort of wireless is still probably the better option.


Well, I pray that Hyperlink will respond to my request........
And even if they decline to donate, at least maybe they will offer a solution and then we can work with that.......
____________
******************
Crunching Seti, loving all of God's kitties.

I have met a few friends in my life.
Most were cats.

Profile KyleFL
Send message
Joined: 20 May 99
Posts: 17
Credit: 2,289,892
RAC: 0
Germany
Message 817492 - Posted: 12 Oct 2008, 11:37:05 UTC - in response to Message 817282.

It should be quite easy to setup an WLAN Link from top of the hill to the central campus.
I have done such a link @ with 2 Linksys WAP54G and it was quite easy.
The usable bandwith was ~20MBit, but now with the new Draft-N WLAN Hardware, that should be 5-8times faster.
That additional bandwith does come very cheap and without long installation issues.

They need 1000 megabits (1 gigabit) and probably more than a mile with good link budgets.

In other words, something better than draft-N.

Some sort of wireless is still probably the better option.


Yes -- but I thought everything that can give additional bandwith is better than not doing anything!
So an additional bandwith of ~100MBit would still double the actual link.
____________

PhonAcq
Send message
Joined: 14 Apr 01
Posts: 1622
Credit: 21,574,483
RAC: 2,872
United States
Message 817599 - Posted: 12 Oct 2008, 16:36:40 UTC - in response to Message 816451.

I think Jon's idea is the most possible solution to distributing the back-end workload. It's worth pursuing, at least academically, but my mind reels thinking about the minor issues, at least in our case, that may make such an endeavour ultimately not worth it (at the moment). The devil is in the details.

- Matt


To restart this thread (a bit), has anyone thought that the first step might be to set up a stand alone server at Berkeley to simulate the distributed backbone idea? A sort of beta project. There seems to be some extra computer hardware there, albeit not suitable to be part of the central cluster. If one could be set up and made useful (actually use it in production on a limited subset of data, as described below), it might find a home at a distributed site (NCU in the example below) since the start-up costs would be minimized and the probability of success maximized. In addition to potentially improving the system in the short term, the lessons learned might accelerate the DT idea, when future hardware donations or partners are available.

Before the naysayers (NL) get too excited, everyone already knows that this would take resources. Resource allocation is for the staff to decide in the end and is not worth arguing here.

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817606 - Posted: 12 Oct 2008, 16:42:16 UTC - in response to Message 817492.

It should be quite easy to setup an WLAN Link from top of the hill to the central campus.
I have done such a link @ with 2 Linksys WAP54G and it was quite easy.
The usable bandwith was ~20MBit, but now with the new Draft-N WLAN Hardware, that should be 5-8times faster.
That additional bandwith does come very cheap and without long installation issues.

They need 1000 megabits (1 gigabit) and probably more than a mile with good link budgets.

In other words, something better than draft-N.

Some sort of wireless is still probably the better option.


Yes -- but I thought everything that can give additional bandwith is better than not doing anything!
So an additional bandwith of ~100MBit would still double the actual link.

Given that they need to cover at least a mile, and that I'd expect other devices on the air in the 2.4 GHz band at both ends, I probably would not try to do 802.11a/b/g or draft-N.

I'd worry about reliability issues with other occupants on those frequencies.

That's a part of the "link budget" -- you want the signal at both ends to be above the likely noise floor.

You've also got path loss, which will vary with weather.

... and we don't know for sure where they'd be able to connect at faster than 100 megabits (Matt said it'd mean replacing routers at both ends, so to save the cost of another router we need to bring the signal to the right place).

That's why I said some kind of wireless would be good, but not necessarily consumer level gadgets with better antennas.

Whatever is offered also should be maintainable: anything we'd kluge together is likely to require repair from time to time.

... and if we can get a donation, we might as well go for something that does the whole job, and is built for the task.

I haven't found pricing, but Bridgewave is one of the vendors that makes the right kind of stuff. On the 80GHz band, they're talking about six miles -- and it would not have to beat out somebody's cordless phone.
____________

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817613 - Posted: 12 Oct 2008, 16:47:52 UTC - in response to Message 817599.

I think Jon's idea is the most possible solution to distributing the back-end workload. It's worth pursuing, at least academically, but my mind reels thinking about the minor issues, at least in our case, that may make such an endeavour ultimately not worth it (at the moment). The devil is in the details.

- Matt


To restart this thread (a bit), has anyone thought that the first step might be to set up a stand alone server at Berkeley to simulate the distributed backbone idea? A sort of beta project. There seems to be some extra computer hardware there, albeit not suitable to be part of the central cluster. If one could be set up and made useful (actually use it in production on a limited subset of data, as described below), it might find a home at a distributed site (NCU in the example below) since the start-up costs would be minimized and the probability of success maximized. In addition to potentially improving the system in the short term, the lessons learned might accelerate the DT idea, when future hardware donations or partners are available.

Before the naysayers (NL) get too excited, everyone already knows that this would take resources. Resource allocation is for the staff to decide in the end and is not worth arguing here.


Probably the best place to start is to look at the other projects that have distributed their servers to various campuses.

SETI would not be the first. I think CPDN either did, or does currently.

It'd be interesting to learn what they found as to advantages and problems.
____________

Profile Mumps [MM]
Volunteer tester
Avatar
Send message
Joined: 11 Feb 08
Posts: 4454
Credit: 8,512,938
RAC: 396
United States
Message 817633 - Posted: 12 Oct 2008, 17:10:00 UTC - in response to Message 817613.

I think Jon's idea is the most possible solution to distributing the back-end workload. It's worth pursuing, at least academically, but my mind reels thinking about the minor issues, at least in our case, that may make such an endeavour ultimately not worth it (at the moment). The devil is in the details.

- Matt


To restart this thread (a bit), has anyone thought that the first step might be to set up a stand alone server at Berkeley to simulate the distributed backbone idea? A sort of beta project. There seems to be some extra computer hardware there, albeit not suitable to be part of the central cluster. If one could be set up and made useful (actually use it in production on a limited subset of data, as described below), it might find a home at a distributed site (NCU in the example below) since the start-up costs would be minimized and the probability of success maximized. In addition to potentially improving the system in the short term, the lessons learned might accelerate the DT idea, when future hardware donations or partners are available.

Before the naysayers (NL) get too excited, everyone already knows that this would take resources. Resource allocation is for the staff to decide in the end and is not worth arguing here.


Probably the best place to start is to look at the other projects that have distributed their servers to various campuses.

SETI would not be the first. I think CPDN either did, or does currently.

It'd be interesting to learn what they found as to advantages and problems.

If I recall correctly, Einstein also has a partially distributed distribution system. :-)

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817648 - Posted: 12 Oct 2008, 17:37:03 UTC - in response to Message 817633.


SETI would not be the first. I think CPDN either did, or does currently.

It'd be interesting to learn what they found as to advantages and problems.

If I recall correctly, Einstein also has a partially distributed distribution system. :-)

I seem to remember that CPDN actually lost one of their partners at some point, which was a real problem.

Seems the upload URL is supplied with the WU, and not only did the server disappear, but it disappeared from DNS and they had trouble getting something into their DNS pointed to a valid server.

For CPDN, since work units run so long, it takes a year to collect the answers.

The solution of course is to keep all of the upload DNS names under the control of the project, and put in the right A records or CNAMEs.

... but it's just one of the issues when you start trying to spread the load.
____________

Profile Jon Golding
Avatar
Send message
Joined: 20 Apr 00
Posts: 56
Credit: 362,669
RAC: 26
United Kingdom
Message 817705 - Posted: 12 Oct 2008, 18:50:34 UTC

On the subject of distributed servers, is anyone here in contact with the developers at CPDN or Einstein? They should be brought into this discussion (perhaps in a separate thread of its own).
____________

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817711 - Posted: 12 Oct 2008, 19:03:57 UTC - in response to Message 817705.

On the subject of distributed servers, is anyone here in contact with the developers at CPDN or Einstein? They should be brought into this discussion (perhaps in a separate thread of its own).

I believe that the BOINC project community is as vital as this one (if a bit smaller).

This isn't going to happen very fast: SETI@Home is about three very busy staffers, and that's about it. Doing this is yet another task added to an already very busy queue.
____________

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817715 - Posted: 12 Oct 2008, 19:07:53 UTC - in response to Message 817599.

Before the naysayers (NL) get too excited.

I'm not "excited" I'm realistic.

You and I are not the ones doing the work, and I'm reluctant to add to someone elses' workload when they are not my employee.

So it's fun to play armchair quarterback, but unless we specifically fund a project like this, what we're really doing is only going to happen if the people who work in the lab at Berkeley decide to divert resources to that idea.

____________

Profile Jon Golding
Avatar
Send message
Joined: 20 Apr 00
Posts: 56
Credit: 362,669
RAC: 26
United Kingdom
Message 817745 - Posted: 12 Oct 2008, 19:36:48 UTC - in response to Message 817715.

You and I are not the ones doing the work, and I'm reluctant to add to someone elses' workload when they are not my employee.
So it's fun to play armchair quarterback, but unless we specifically fund a project like this, what we're really doing is only going to happen if the people who work in the lab at Berkeley decide to divert resources to that idea.


I'm sorry, Ned, but I fully support PhonAcq on this one.

Admittedly, I don't have either the technical skill nor the time to make any of this happen, so I certainly fall into your "armchair quarterback" category.

However, would we be adding to the Berkeley staff workload by asking experts that already use distributed servers for other projects within the BOINC community to come up with viable suggestions for how SETI could also do this?
Moreover, in conjunction with the advice from other BOINC projects, we have a vast resource of professional programmers within the SETI community who might enjoy the challenge of adapting the open source software to create a viable distributed server platform (take Lunatics, for example).

None of this requires the day-to-day input from the SETI staff. They'd obviously need to be involved in initial discussions about what they wanted and to lay down ground rules, but after that they'd just require a progress update from time to time, to ensure that any development was still compatible with their requirements.
____________

OzzFan
Volunteer tester
Avatar
Send message
Joined: 9 Apr 02
Posts: 13307
Credit: 27,863,867
RAC: 15,842
United States
Message 817758 - Posted: 12 Oct 2008, 20:04:20 UTC - in response to Message 817745.

You and I are not the ones doing the work, and I'm reluctant to add to someone elses' workload when they are not my employee.
So it's fun to play armchair quarterback, but unless we specifically fund a project like this, what we're really doing is only going to happen if the people who work in the lab at Berkeley decide to divert resources to that idea.


I'm sorry, Ned, but I fully support PhonAcq on this one.

Admittedly, I don't have either the technical skill nor the time to make any of this happen, so I certainly fall into your "armchair quarterback" category.

However, would we be adding to the Berkeley staff workload by asking experts that already use distributed servers for other projects within the BOINC community to come up with viable suggestions for how SETI could also do this?
Moreover, in conjunction with the advice from other BOINC projects, we have a vast resource of professional programmers within the SETI community who might enjoy the challenge of adapting the open source software to create a viable distributed server platform (take Lunatics, for example).

None of this requires the day-to-day input from the SETI staff. They'd obviously need to be involved in initial discussions about what they wanted and to lay down ground rules, but after that they'd just require a progress update from time to time, to ensure that any development was still compatible with their requirements.


And therein lies the problem. You're not adding to the Berkeley staff workload because the Berkeley staff does not help out with SETI@Home chores. Also, having plenty of experience designing projects, you're always bound to run into unforeseen problems and will need input from somebody "in the know" and as such will be constantly questioning Matt or Eric or whoever for more input. It would be much more than just laying the ground rules and then off you go.

The software programmers would have to have intimate knowledge of the system, and unless its documented 100%, and very clearly, this is where asking Matt or Eric for clarification will come in on a constant basis to ensure that it works correctly - then there's the field test and the tweaking and the rewriting; rinse, lather, repeat until completed (and no project is ever complete, there's always tweak that need to be added later).

I'm not trying to discourage this in any way, though I know some of you are going to take it that way. I just don't think you guys fully realize the scope of what you want to do, and I base this opinion that you guys don't know upon the fact that, in theory, you state that minimal work will be required by the guys on campus - but they are the ones that would need to be integral to the entire project/idea.

I honestly hope that something can be done to load balance the servers, and I hope you guys keep brainstorming ideas, but just realize that about anything you come up with is going to require lots of involvement from an already busy staff who may not be able to devote the time to implement the idea you come up with.

1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 817797 - Posted: 12 Oct 2008, 21:58:55 UTC - in response to Message 817745.
Last modified: 12 Oct 2008, 21:59:55 UTC

You and I are not the ones doing the work, and I'm reluctant to add to someone elses' workload when they are not my employee.
So it's fun to play armchair quarterback, but unless we specifically fund a project like this, what we're really doing is only going to happen if the people who work in the lab at Berkeley decide to divert resources to that idea.


I'm sorry, Ned, but I fully support PhonAcq on this one.

Admittedly, I don't have either the technical skill nor the time to make any of this happen, so I certainly fall into your "armchair quarterback" category.

However, would we be adding to the Berkeley staff workload by asking experts that already use distributed servers for other projects within the BOINC community to come up with viable suggestions for how SETI could also do this?
Moreover, in conjunction with the advice from other BOINC projects, we have a vast resource of professional programmers within the SETI community who might enjoy the challenge of adapting the open source software to create a viable distributed server platform (take Lunatics, for example).

None of this requires the day-to-day input from the SETI staff. They'd obviously need to be involved in initial discussions about what they wanted and to lay down ground rules, but after that they'd just require a progress update from time to time, to ensure that any development was still compatible with their requirements.

... and you certainly may support PhonAcq.

I actually think this is a very good idea.

What I'm trying to point out is, no matter who sits back and who does the initial footwork, at some point, Matt, Jeff and Eric will have to do the work.

If they're building a server to ship off to some other site, and configuring it, plus the politics (for lack of a better term) of having another organization take care of that server, they're the ones that have to do it.

I even agree that once it's deployed, there isn't that much operational work to continue operating that way.

It even occurred to me that a "burn in" period with the "remote" server in a different building on campus would be a great idea -- far enough that they can't just walk into the lab and kick it, and close enough that they can go there if needed.

I'm only saying that no matter how good an idea is, we have to realize that the available resources are pretty well fully allocated, and if this would take 20 man-hours to set up, that's 20 man-hours that have to come from something else (that we probably want).

I also suspect that if they had a server to ship off someplace else that they could probably gain the same boosts in performance keeping it at the lab, but that's a different discussion.

I'm not saying that it should not be suggested, just that we need to be realistic -- if it happens, it won't happen fast, and there isn't much we can do from the outside to rush it along.

I also think there is this goofy perception that the SETI servers need 99.999% reliability, when something in the high 80% range really is good enough.

-- Ned
____________

Profile doublechaz
Send message
Joined: 17 Nov 00
Posts: 66
Credit: 31,566,637
RAC: 10,266
United States
Message 817985 - Posted: 13 Oct 2008, 9:54:11 UTC

Is it the fibre itself that is 100Mbit or is it the interfaces in the routers that are limited? I thought you could run Gbit that far over fibre with the correct WICs in the routers. Certainly it is multimode fibre to go that far.

I work at a wireless ISP, so I don't know fibre that well.

As to a wireless link you could use a couple RouterBoards from MikroTik with a pair of wireless A cards at each end. Then teach it to use the Nstream Dual protocol instead of 802.11 and you could get something like 40Mbit full duplex. That wouldn't cost much. I think we could raise donations for the couple thousand it would take.

I can contribute technical skill on the RouterBoard setup if there is interest.
____________

Bounce
Send message
Joined: 3 Apr 99
Posts: 66
Credit: 5,604,569
RAC: 0
United States
Message 818073 - Posted: 13 Oct 2008, 16:08:32 UTC

long distances (iirc beyond 2 Km) = single mode fibre
short haul = multi mode fibre
____________

piper69
Send message
Joined: 25 Sep 08
Posts: 49
Credit: 3,042,244
RAC: 0
Romania
Message 818077 - Posted: 13 Oct 2008, 16:22:52 UTC

the best solution to this is still the 1gb conn.

faster speed . easyer to maintain. reduced real workhours

Previous · 1 · 2 · 3 · 4 · Next

Message boards : Technical News : Bit Ceiling (Oct 08 2008)

Copyright © 2014 University of California