Krzysztof Halasa wrote:
Ben Greear <[email protected]> writes:
I think if I could support these scenarios below, I would have
everything I need:
* Configure T1 as unchannelized bitstream, bridge entire thing to
second T1.
I think it should be easy with such card, though I think the drivers
can't currently do that.
At least some out-of-tree drivers seem to be able to do this. For
instance, these guys:
http://www.farsite.co.uk/
* Configure channels 1-5 as a bitstream and bridge that to channels
1-5
of a second T1. (random proprietary bit-streaming protocol,
I think the hardware would permit that. Probably needs additional
driver support and I'm not sure about timeslot synchronization (for
HDLC, sync doesn't matter).
My assumption for bridging a bitstream is that timeslot sync is not
absolutely critical. However, IF
you could be sure of time-slot sync, you'd have a lot more power and be
able to do some extra ticks
in user-space I think...
would probably bridge HDLC just fine, but handling
HDLC as frames would be more efficient I think.)
Not sure, maybe yes (less data to bridge due to bit stuffing, flags etc.),
maybe not (variable length of HDLC frame).
The key for me is that if you ever miss a slot in bit-stream mode, you
can never make it up because
every bit is critical. This leads to having to drop arbitrary data to
keep from ever-increasing latency on your
bridge. With HDLC, you can skip the flags and make up time if you ever
miss a timeslot (assuming the
HDLC is not using the line at 100% capacity.)
channels 6-10 configured as an HDLC interface, bridged as HDLC
frames to channels 6-10 of a second T1. (PPP & other protocols over
HDLC)
channels 10-24 each configured as a separate bit-stream, bridged to
channels 10-24 on the second T1. (Voice)
I think the above could be a problem - I think common T1/E1 cards
can do only one stream at once.
I wonder if it can be done in software - the hardware framer would
have to pass all data transparently, and it would be demultiplexed,
processed and then multiplexed by the driver. Quite complicated,
but I think at 2 Mbps it wouldn't be a CPU performance problem.
I'd be happy with a software approach. In fact, if I could get a framed
packet (ie, I know that
byte 0 is channel 1, byte 24 is channel 24, and byte 25 is channel 1
again...) then I could even
do the multiplexing in user space.
For write, I'd also need to be able to guarantee that byte 0 goes to
channel 1, etc. So, if the
driver bit-stuffed, then it would need to do an entire time-slice at once.
* Configure entire T1 as HDLC transport, bridge HDLC frames from one
T1 to the other.
Easy even with existing drivers I think (no bridge support but it's
trivial).
Excellent. I actually want to write the bridge logic myself in
user-space..I just need the driver
API and at least one driver that supports it and has support for readily
available T1/E1 hardware.
For future work, I'd be interested in the same sort of support for DS3/E3.
I'd be willing to fund development of these features if you or someone
else is interested
(please contact me off list for details.)
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
