Subject:
|
Re: GBC at BrickFest 2006
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 6 Sep 2006 20:55:52 GMT
|
Viewed:
|
4559 times
|
| |
|
|
In lugnet.robotics, Juergen Stuber wrote:
> I downloaded it completely and don't see any jerkiness,
You're correct, I was streaming it from Google which was probably the issue.
> > Because of the standard throughput requirement (that each
> > module must handle at least 1 ball per second, or "bps"),
> > a module *can't* be overwhelmed, as long as the first
> > module in a line never releases balls at more than 1 bps
> > or so.
>
> But then it may need to accept a lot of balls,
> if the other modules are quicker.
It doesn't matter how much quicker than the standard a single module is - if it
only gets 1 bps, then it can only pass them to the downstream module at 1 bps...
any faster, and it will "run dry", and not have any more balls to deliver until
this "fast" module gets another ball from its upstream side. there are two
possible problems with this:
1) The train unloading modules take a beating in the bulk ball delivery
department. Both Steves and mine are built to reliably handle more than 60 balls
at once, in order to handle unlaoding two full train cars in a short period of
time. I'd classify the train unloaders as "special" modules in this regard - a
lot of modules still have problems with a batch of 10-20 balls delivered at
once.
2) Yes, you could technically store up, say, 300 balls, and then according to
the spec release them as ten batches of 30 balls each, at intervals of 1 second,
before the module goes into "accumulate" mode again for five minutes. But we
figured if you were planning on being that mean, you weren't going to play well
with others in the GBC in the first place <grin>. Seriously, the intention of
the standard was to maintain interest (1 bps was deemed an "interesting" enough
rate) while not overwhelming, and since some mechanisms clearly episodicly
dumped balls in bulk into the next module, we wanted to make sure those
"batches" were of reasonably managable size (30 balls or less, presumably at
roughly 30 second intervals).
> there's nothing against that in the spec.
Correct. But there's lots against that in the *intent* of the spec.
--
Brian Davis
|
|
Message is in Reply To:
 | | Re: GBC at BrickFest 2006
|
| (...) I downloaded it completely and don't see any jerkiness, maybe that was due to streaming it as the bandwidth from Google was a bit low (< 100kB/s). (...) But then it may need to accept a lot of balls, if the other modules are quicker. I know (...) (18 years ago, 6-Sep-06, to lugnet.robotics)
|
28 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
