T.R | Title | User | Personal Name | Date | Lines |
---|
885.1 | A/D converter = NEMESYS box | LEMAN::CHEVAUX | Patrick Chevaux @GEO, DTN 821-4150 | Wed Apr 02 1997 13:46 | 7 |
| To be precise
.0� There is a camera connected to
a NEMESYS box connected to
.0� one of the ports (6.3) and a screen to
|
885.2 | D/A converter also a NEMESYS box | LEMAN::PAIVA | Hawkeye - Network Support @GEO | Wed Apr 02 1997 19:49 | 6 |
| Well, if you really want to be precise, there's an ATA between the video
camera and port 6.3 and an ATV between port 6.4 and the screen...
...but I don't think we're getting very far this way!
Pedro
|
885.3 | Re: P-MP ABR problem on a GS/ATM | QUABBI::"[email protected]" | Hal Murray | Fri Apr 04 1997 19:02 | 18 |
| If we use an ABR P-P PVC, or a CBR P-MP PVC (100Mbps) the image passes
fine. However if we use an ABR P-MP PVC the image isn't at all
acceptable (even if we set the rate of image transmission at 1 Mbps).
The PVC is set as 0/240 on input (6.3) and 0/240 on output (6.4).
The P-MP PVCs only have one branch.
ABR P-P and CBR (P-MP or P-P) are done in hardware.
ABR P-MP requires software help. I don't know what the throughput will be
but it won't be good. It may be bursty if the CPU takes time out to do
something else like setup an SVC or think about the tolology when a new
switch in connected up.
I think you have to use CBR if you want P-MP. That has the obvious
complication of not being able to overallocate the bandwidth on any link.
[posted by Notes-News gateway]
|
885.4 | | LEMAN::PAIVA | Hawkeye - Network Support @GEO | Sat Apr 05 1997 04:31 | 21 |
| Hal,
Thanks for your answer. But...
>ABR P-P and CBR (P-MP or P-P) are done in hardware.
Good to know.
>ABR P-MP requires software help. I don't know what the throughput will
>be but it won't be good. It may be bursty if the CPU takes time out to do
>something else like setup an SVC or think about the tolology when a new
>switch in connected up.
Why does it require software help and what kind of help is that? What
about if the GS/ATM isn't doing anything else (we could disconnect
everything else)? Will this situation change when we'll support ABR
with a garanteed bandwidth?
Thanks.
Pedro
|
885.5 | p-mp is a linecard problem, not GS/ATM | NOTED::defctb.hpn.lkg.dec.com::melaragni | Bill, [email protected] | Mon Apr 07 1997 09:04 | 14 |
| In the current generation of linecards there is no hardware mechanism for
replicating cells that are sent across the backplane. Without cell
replication, the linecard has to generate each cell individually and then
re-transmit them as many times as there are p-mp VCs. Each time the cell
is re-transmitted it must be modified with a new VC. This process is
handled by the micro on board the "source" linecard.
If i recall, and i ask others to corrobarate this, the QLCv2 can inject
cells at the rate of 3-4 Mbit/s via the microprocessor. I believe that this
bandwidth is divided into the number of p-mp VCs supported, so 2 p-mp VCs
would have about 1.5-2 Mbit/s available to each, etc.
Hope this helps,
bill
|
885.6 | for now, Gsw/ATM only does CBR p-mp in hardware | NPSS::WATERS | I need an egg-laying woolmilkpig. | Mon Apr 07 1997 09:55 | 14 |
| Answer .-1 will probably confuse people.
Gsw/ATM line cards do indeed have the ability to replicate cells in
hardware as they cross the backplane. But only for CBR VCs. Thus
hardware point-to-multipoint service is provided only for CBR P-Mp VCs
at present. A few megabits per second of outbound p-mp service can be
emulated by the line card processors, but that's too slow for most
applications.
A third generation of line cards will increase our set of p-mp services,
among other new features.
Any time someone mentions "ABR P-Mp" service, they are really talking
about "UBR P-Mp" service. No ATM switch has the ability to merge RM
cells from multicast branches toward the p-mp source. Thus the Forum
ABR service is strictly impossible for p-mp VCs with today's switches.
|
885.7 | 1Mbps should be enough... | LEMAN::PAIVA | Hawkeye - Network Support @GEO | Mon Apr 07 1997 10:02 | 16 |
| Hi again!
In .0 when I wrote "Are we trying something wired or is there a
problem?", of course it is wired, but I meant weird ;-)
Re: .5
I don't really understand the difference between a P-P ABR and a
P-MP ABR with MP=1 (except the hw/sw difference which difference I
could clearly see...) Should there be a difference between using a QLC
V1.5 and a QLC V2.0?
Thanks.
Pedro
|
885.8 | Re: P-MP ABR problem on a GS/ATM | QUABBI::"[email protected]" | Hal Murray | Mon Apr 07 1997 13:49 | 19 |
| In article <[email protected]>, [email protected] (Hawkeye - Network Support @GEO) writes:
> Why does it require software help and what kind of help is that? What
> about if the GS/ATM isn't doing anything else (we could disconnect
> everything else)? Will this situation change when we'll support ABR
> with a garanteed bandwidth?
It requires software because the hardware can't handle that case. The GS/ATM
is a crossbar (not a time-shared bus). The tricky part of building a
crossbar is figuring out how to schedule things - which line sends to
which other line during a cell slot. Things get more complicated if
you have to send a cell to more than one other line. The CBR case turned
out to be easy. We didn't have any good ideas for the ABR case and
we didn't think it was important so we didn't worry about it.
So the software for that case has to process each cell - sending it to all
the outbound VCs one at a time.
[posted by Notes-News gateway]
|