PDA

View Full Version : Cachecard network burst mode



jafa
12-19-2004, 01:15 PM
Hi all,

I have been playing around with a proof of concept.

The cachecard ethernet interface can theoretically go really fast but it is held back by the software achitecture on the TiVo.

With my TiVo I typically see approx 1MB/s (8Mbps) harddrive to network speeds.

I have just completed a proof of concept for a burst mode - clocked up a sustained harddrive to network speed of 5.6MB/s (45Mbps) on the same TiVo.

Edit: New test... transfered 95780380 bytes in 12.352 seconds = 62Mbps = 7.75MB/s :)

Nick

JJBliss
12-19-2004, 01:26 PM
Feel free to discuss it further here if you like.

Replicatable on Series 2 units or is it a hardware modification to your cachecards?

jafa
12-19-2004, 03:13 PM
It is an update to the cachecard drivers to make use of the bursting features of the cachecard. It links the IDE cache interface to the ethernet interface.

The API is an ioctl - you specify the sector range and the destination PC and it will burst the data out the network interface.

The communication is over UDP - as long as the PC can handle the data rate there should be low loss over an internal network. Lost data can be re-requested.

A second conventional TCP channel should be used to manage the transfer.

45Mbps was achieved with a 64k block size and 4 threads.

Nick

schottjy
12-19-2004, 04:11 PM
Brilliant.. So close to buying a CacheCard now :)

Jamie
12-19-2004, 04:31 PM
The communication is over UDP - as long as the PC can handle the data rate there should be low loss over an internal network. Lost data can be re-requested.
Sounds interesting, but unless I'm missing something, all the user mode software (both client and server) is going to have to be replaced to use UDP.

For what it's worth, at least one (http://www.dealdatabase.com/forum/showthread.php?postid=197736#post197736) user is reporting >3MB/sec with the existing cachecard drivers and the latest tserver, which has internal performance improvements that reduce CPU load. Still a far cry from 45Mb/sec but much better than 8Mb/sec.

jafa
12-19-2004, 10:15 PM
New test...

Transfered 95780380 bytes in 12.352 seconds = 62Mbps = 7.75MB/s :)

Still tweeking :)

sanderton
12-20-2004, 06:58 AM
What software are you using at the PC end? Is the sector range representing part file stored in MFS, if not, how might you get it?

rbiro
12-22-2004, 04:39 PM
The communication is over UDP - as long as the PC can handle the data rate there should be low loss over an internal network. Lost data can be re-requested.

A second conventional TCP channel should be used to manage the transfer.

45Mbps was achieved with a 64k block size and 4 threads.

Nick

So would that mean that the core hacking software

mfs_ftp
tserver
vserver

would have to be modified to take advantage of the significant throughput improvements?

What about the PC side software?

laserfan
12-24-2004, 12:24 PM
New test...

Transfered 95780380 bytes in 12.352 seconds = 62Mbps = 7.75MB/s :)

Still tweeking :)Your post made me sufficiently weak-in-the-knees to order a cachecard from 9thtee.

Now you gots to deliver! Presumably your tweaks will work w/o new cachecard firmware (latest 2.2 I think)?

jafa
12-24-2004, 01:45 PM
Yep - it works with any cachecard... I will have test program to download and try in the next two weeks.

jafa
12-25-2004, 03:21 PM
Ok, test program...

Edit - updated installer link is in post below.

There are a number of tweakable parameters... in the next few days I will convert them to be command line parameters so you can play with them.

BTW XP SP2 has serious network performance problems. If it is transfering data but getting overflow/timeout messages, this usually indicates that your PC can't keep up.

I am seeing approx 50Mbps with this test program. I have seen >60Mbps but it will take a bit more software work to get right.

Installation on tivo - see readme.txt.

When you run burst.exe it will give an example for transfering the root partition - this is a good test.

Nick

laserfan
12-26-2004, 11:05 AM
So many people are having so much trouble with so many programs with XP SP2--I'm glad I have a slow Internet connection. I'm not even tempted to upgrade (from SP1 + hotfixes).

Anyway DL'ing the zip now and looking forward to playing with what, a 10x improvement? Too early for higher math this day-after.

My Tivonet card works great and I have all the time-in-the-world, but I really like this hardware hacking stuff. Thanks!

jafa
12-26-2004, 01:46 PM
Edit - updated installer link is in post below

jafa
12-26-2004, 05:20 PM
Native driver installer:
http://www.silicondust.com/nic_install_tivo_20041226.zip

Installation instructions:
http://www.silicondust.com/forum/viewtopic.php?t=340

Once installed, reboot, telnet in and run:
burstd

PC program::
http://www.silicondust.com/burst_20041226.zip

Speed test (backup root filesystem):
burst //192.168.0.200/0:7:0-262144 root7.bak

rbiro
12-26-2004, 08:14 PM
Here are my results:

PC: P4, 2.6 GHz, WinXP SP2
TiVo: Sony SVR-2000 (SA1). (The TiVo was in standby mode and not recording.)

Using burst_test_20041226.zip

Network topology is:
PC to Linksys 5 port switch to Linksys 4 port router to Cachecard

Results:
transfered 134217728 bytes in 36.984000 seconds = 29.032604 Mbps
transfered 134217728 bytes in 33.172000 seconds = 32.368920 Mbps
transfered 134217728 bytes in 37.547000 seconds = 28.597273 Mbps

So I'm not getting 60-75 Mbps that Jafa is, but it is at least 3x faster than my best FTP...

Output from 1st transfer:

C:\burst_test_20041226\pc>burst //192.168.1.23/0:7:0-262144 root7.bak
sending request for 0:7:00000000-00008000
sending request for 0:7:00006ef2-00006ef5
rx overflow or timeout
sending request for 0:7:00002536-00002564
rx overflow or timeout
sending request for 0:7:00008000-00010000
sending request for 0:7:0000bf25-0000bf31
rx overflow or timeout
sending request for 0:7:0000b480-0000b483
rx overflow or timeout
sending request for 0:7:0000b3aa-0000b3cd
rx overflow or timeout
sending request for 0:7:00010000-00018000
sending request for 0:7:00014ec4-00014edf
rx overflow or timeout
sending request for 0:7:00018000-00020000
rx overflow or timeout
sending request for 0:7:0001fa1c-0001fa28
rx overflow or timeout
sending request for 0:7:0001aa69-0001aa7e
rx overflow or timeout
sending request for 0:7:0001a925-0001a956
rx overflow or timeout
sending request for 0:7:00020000-00028000
sending request for 0:7:00020c99-00020ca3
rx overflow or timeout
sending request for 0:7:00028000-00030000
sending request for 0:7:0002e827-0002e82e
rx overflow or timeout
sending request for 0:7:000295fa-00029603
rx overflow or timeout
sending request for 0:7:000294de-000294f0
rx overflow or timeout
sending request for 0:7:00030000-00038000
sending request for 0:7:0003707a-000370cd
rx overflow or timeout
sending request for 0:7:000318b6-000318cb
rx overflow or timeout
sending request for 0:7:00038000-00040000
sending request for 0:7:0003f444-0003f480
rx overflow or timeout
sending request for 0:7:0003c4ef-0003c4fb
rx overflow or timeout
sending request for 0:7:0003a6db-0003a700
rx overflow or timeout
sending request for 0:7:0003a352-0003a378
rx overflow or timeout
sending request for 0:7:0003a200-0003a20c
rx overflow or timeout
sending request for 0:7:0003a10b-0003a10f
rx overflow or timeout
sending request for 0:7:00039a3e-00039a53
rx overflow or timeout
sending request for 0:7:00039908-00039934
rx overflow or timeout
transfered 134217728 bytes in 36.984000 seconds = 29.032604 Mbps

rbiro
12-26-2004, 08:20 PM
Nick,

you have a problem with the .cpio file. You are missing ther new files.

./nic_install_tivo cachecard


Copying files...
cp: ./libpthread.so.0: No such file or directory
cp: ./burstd: No such file or directory
Complete.



Native driver installer:
http://www.silicondust.com/nic_install_tivo_20041226.zip

Installation instructions:
http://www.silicondust.com/forum/viewtopic.php?t=340

Once installed, reboot, telnet in and run:
burstd

PC program::
http://www.silicondust.com/burst_20041226.zip

Speed test (backup root filesystem):
burst //192.168.0.200/0:7:0-262144 root7.bak

jafa
12-26-2004, 08:23 PM
Hi,

I have just fixed it... please download and try again.

Also, please download the newer updated burst.exe - that might solve some of the overflows you are seeing.

Nick

rbiro
12-26-2004, 09:07 PM
On My P4, WinXP SP2 box:

Still get the rx overflow or timeout messages

32-34 Mbps

From my P3 800 MHz running Win2K

C:\Temp\burst_20041226>burst //192.168.1.23/0:7:0-262144 root7.bak
sending request for 0:7:00000000-00008000
sending request for 0:7:00008000-00010000
sending request for 0:7:00010000-00018000
sending request for 0:7:00018000-00020000
sending request for 0:7:00020000-00028000
sending request for 0:7:00028000-00030000
sending request for 0:7:00030000-00038000
sending request for 0:7:00038000-00040000
transfered 134217728 bytes in 32.187000 seconds = 33.359487 Mbps

I get no errors, but no faster throughput.

jafa
12-27-2004, 02:14 AM
Interesting...

The errors are generated when the PC gets flooded and can't keep up with the packet rate.

XP SP2 is *really* bad with incomming packets. It doesn't suprise me that your old 800MHz machine running Win2K can out perform it :(

Win2K, XP org and XP SP1 will work well. My 2.8GHz P4 running XP SP2 can keep up if it isn't running anything else.

Ironically I can do a packet capture at the same time and capture all the dropped packets - the pc is receiving them but the the network stack is dropping them higher up.

A SA TiVo is approx 3/4 of the speed of DTiVo so that may account for some of the speed difference. Also there are a number of tunable parameters and my default testing is on a DTiVo so it may not be optimal for a SA.

I plan to do a release later this week that will allow you to tune the different parameters that affect performance.

Nick

rung
12-27-2004, 06:55 AM
Interesting...
XP SP2 is *really* bad with incomming packets.Does it have anything to do with the XP SP2 firewall? Have you tried turning it off during your tests?

Regards,
Rung

rbiro
12-27-2004, 02:22 PM
Does it have anything to do with the XP SP2 firewall? Have you tried turning it off during your tests?

Regards,
Rung

See next post...

rbiro
12-27-2004, 03:48 PM
A little digging...



From Support.Microsoft.com (http://support.microsoft.com/?kbid=842264)
SYMPTOMS
After you install Microsoft Windows XP Service Pack 2 (SP2), you may experience a significant slowdown in network performance and in data throughput on your computer.
CAUSE
This issue may occur because Windows Firewall does work correctly with Large Send Offload (LSO) if all the following conditions are true:
• You use a high-speed network environment. For example, you use gigabit network cards, hubs, switches, routers, and target file servers.
• Your network card and its driver support using LSO.
• Your Windows XP-based computer sends lots of data to a server.
WORKAROUND
To work around this issue, disable the Windows Firewall/Internet Connection Sharing service. To do this, follow these steps:
1. Click Start, click Run, type services.msc, and then click OK.
2. In the Services list, right-click Windows Firewall/Internet Connection Sharing (ICS), and then click Properties.
3. On the General tab, in the Startup type list, click Disabled, and then click OK.
4. In the Services dialog box, on the File menu, click Exit.
Note This is not equivalent to turning off Windows Firewall in the Security Center. Setting Windows Firewall to Off leaves the component running, and you will still experience the issue. To work around this issue, you must disable the Windows Firewall/Internet Connection Sharing service.
MORE INFORMATION
Large Send Offload (LSO) is a technology where the work of segmenting data into network frames is performed by the network adaptor instead of by the TCP/IP stack. With LSO, TCP/IP sends very large data packets down to the network adaptor driver and the network adaptor hardware. The network adaptor breaks up the data into smaller network-sized frames. This both increases the speed of high-end send operations and decreases the computer's CPU usage because the work is performed on the network adaptor itself. LSO must be implemented in the TCP/IP stack, in the network adaptor hardware, and in the network adaptor driver.
For more information about LSO, visit the following Microsoft Web site: (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/network/hh/network/209offl_f8953328-11cd-4d3d-adb1-496031668b78.xml.asp)




From "thep2pweblog.com" (http://p2p.weblogsinc.com/entry/4341347581391114/)

TCP restrictions in Microsoft’s latest Windows XP service pack—SP2—could slowdown P2P download activity according to a post on Tech-Recipes. It seems that by design SP2 limits the number of simultaneous incomplete outbound TCP connection attempts.
Once the rate is reached, subsequent connection attempts are placed in a queue eventually to be resolved at a fixed rate. Rumors are already around the internet that this slows down programs that open multiple TCP connections at once. Port scanners are a good example of this. Some P2P might be effect as well in theory.


So I guess I need to make sure I have disabled the Service besides turning off the firewall from the Gui.

jafa
12-27-2004, 04:15 PM
I will try this later tonight, but neither situation directly applies.

The first is talking about transmitting bulk tcp data. The only outgoing tcp traffic are the requests (about 32 bytes every few seconds).

The second doesn't apply because it only makes one TCP connection.

Hopefully turning off the service will fix the rx bottle-neck as well.

rbiro
12-27-2004, 08:32 PM
I was finally able to get into my PC and check the XP Services.
The "Windows Firewall/Internet Connection Sharing (ICS)" was already disabled.

So the rx overflow or timeout errors were not related to that.

mikealbon
12-31-2004, 05:36 AM
I would like to try this burst mode driver, but I don't have any windows at home. Is there a linux version of the client program? (or can there be one?)

Mike

CrimsonBrian
01-20-2005, 11:59 AM
Awesome! This burst mode worked like a charm when I tried it out, I got abotu 36 Mb/s. Now how do I translate that sucess into faster extraction speeds? 1.5 Mb/s is BRUTAL. I am running a SA1 over ethernet, so it should be going faster than that. I recognize that the Tivo CPU is a little clunky but I'm sure it must be able to go faster than that! :) Thanks!

sanderton
01-20-2005, 12:08 PM
Re-write the extraction programs to use this API, and a PC-end program to receive the data and you're there. :)

Maybe Riley & co are working on it already. Or maybe not.

rc3105
01-20-2005, 01:30 PM
yep, maybe half an hour to add support to tystudio/tytool

don't have a cache card though, not planning on buying one either


what'd be interesting is an ide based cache/ethernet card that supports a gig+ of ram and can tranparently intercept/buffer access to mfs & swap partitions

CrimsonBrian
01-20-2005, 02:59 PM
Wow, that is waaay beyond my meager abilities. :) I was just curious if I had missed the second part of the equation. I'll just continue to suffer with my dial-up speeds to my Tivo! :D

jafa
01-20-2005, 03:14 PM
what'd be interesting is an ide based cache/ethernet card that supports a gig+ of ram and can tranparently intercept/buffer access to mfs & swap partitions
That can be done but it works out to be *much* slower than the CacheCard.

The TiVo only issues one read or write request at a time - each can take up to 26ms to seek (on a 9ms drive) plus the data transfer time. All other hard drive requests queue up waiting.

Having the mfs database in disk level cache doesn't help much because it is given lower priority than the video (which is real time) in the pending request queue - the request for data won't get out on the bus until the video data has been transfered.

The cachecard has two key advantages over this:

1) It catches the database request before it goes into the hard drive pending queue - even if there are multiple hard drive requests queued up (which is typical) it can return the data immediatly rather than stalling until all other requests in the queue are completed.

2) It has higher bandwidth to the CPU by using the full 32-bit bus clocked by the FSB.

Nick

rc3105
01-20-2005, 03:57 PM
a solid state device on a uma33 bus is going to have wicked slow seektimes (0 ms?) and fantastic transfer rates. I'd wager it's practical to preempt the read que for the millisecond or two it takes to retrieve the few k that would have otherwise become a 26ms-to-complete-after-waiting-through-the-queue-mfs-read

got any of those quadradrive-cachecards left? should be easy enough to test proof-of-concept code

jafa
01-20-2005, 04:28 PM
a solid state device on a uma33 bus is going to have wicked slow seektimes (0 ms?) and fantastic transfer rates. I'd wager it's practical to preempt the read que for the millisecond or two it takes to retrieve the few k that would have otherwise become a 26ms-to-complete-after-waiting-through-the-queue-mfs-read

got any of those quadradrive-cachecards left? should be easy enough to test proof-of-concept code
Hmmm...

Ok, that is no longer transparent because it requires a change to the ide driver to pre-empt the queue. It would still have to wait for the current transaction to complete - up to 26ms, but only one transaction so isn't too bad.

There is also a problem that it may have to abort the transaction if it isn't in the cache so as not to hold up the next video access request.

The CacheCard has a data throughput rate faster than UDMA33 and doesn't have to wait for the current access to complete. When designing it I reached the point where it was clear that it needed to preempt the queue to get the performance. Following this through, if you have to install drivers then we might as well use the host bus which has higher throughput than the hard drives.

I am playing around with IDE for S2, however for S1 the results are better with the CacheCard.

Nick

rc3105
01-22-2005, 05:21 AM
a transparent mode would of course require the card between the tivo ide bus and the drive so the hd controller never sees requests filled from cache

tivo ide bus <-> (SBC ide bus in target mode)-SingleBoardComp-(SBC ide bus) <-> ide drive(s)

couldn't match the performance of FSB connected cards but would accelerate boxes with stock sw like unhacked series 2.5. read requests would wait through the que normaly, they'd just complete in 1ms instead of 26. anything WITH drivers loaded would see more dramatic improvements from 1ms reads w/o waiting through the que

with "invisible" and "driver-enhanced" modes the trick becomes convincing tivo to add drivers to the stock config ;)


somewhat off topic:

I've often wondered why drives with lots of cache, or at least socketed cache, never really went mainstream. some of the new 250's have 16 meg but that still seems preposterously small when even old quantum 40's can sustain 30 meg/second. 512m on a 400 gig sounds good to me. invisible mode would be usefull in other systems and pure-ramdisk drivers should be fairly simple. could be a much-larger-than-tivoverse market for such a gadget

sanderton
01-22-2005, 01:15 PM
yep, maybe half an hour to add support to tystudio/tytool

don't have a cache card though, not planning on buying one either


So, if generous donors were to send you a cachecard, might you add burst mode support to mfs_ftp?

Presumably a specilal client would be needed PC side.

OT: I see that Tivo2Go is maxing out at 900KB/s!

rc3105
01-22-2005, 03:17 PM
I'd implement a pc-side ftp proxy so you'd just point smart-ftp/IE/<whatever> to 127.0.0.1:3105. (no point re-inventing client sw)

if the transparent ide type card I mentioned a few posts up were avail reasonably cheap I'd add support just for the cool gadget factor (particularly if it had usb or firewire ports). can't really see donating time to cachecard specific utils though. jafa should offer jdiner a grand to add tytool support, that'd sell a LOT of cards...

*gotta think there's somebody in the tivo-verse using tystudio with a cachecard and the skill to add support

sanderton
01-22-2005, 06:31 PM
Anyone got any pointers on how to find the sector addresses of a part file? I'd hoped they might be in MFS, but that would be too easy!

Jamie
01-22-2005, 06:52 PM
Anyone got any pointers on how to find the sector addresses of a part file? I'd hoped they might be in MFS, but that would be too easy!Look at the export_file function in export.c in the unified mfs_* package. The inode for each part lists a number of "runs" with a starting sector and length for each run.

rung
01-22-2005, 07:40 PM
if the transparent ide type card I mentioned a few posts up were avail reasonably cheap I'd add support just for the cool gadget factor (particularly if it had usb or firewire ports).
This type of gadget could also break the trust chain of any protection scheme, couldn't it? You could just return the original sectors when the prom was calculating the hash codes (i.e. it wouldn't realize that the hd had changed). Then again, if it checking what was in memory, not on the hard drive, this wouldn't work. Never mind.

Regards,
Rung

rc3105
01-23-2005, 12:54 AM
This type of gadget could also break the trust chain of any protection scheme, couldn't it? You could just return the original sectors when the prom was calculating the hash codes (i.e. it wouldn't realize that the hd had changed). Then again, if it checking what was in memory, not on the hard drive, this wouldn't work. Never mind.

Regards,
Rung
it's not quite that simple, but with the right procedure it could get you into a series 2.5, xbox, xbox2 or whatnot w/o a prom mod ;)

*looking foreward to loading darwin on the ps3 and xbox2 - revenge of the PPC!!!

sanderton
01-23-2005, 12:07 PM
Look at the export_file function in export.c in the unified mfs_* package. The inode for each part lists a number of "runs" with a starting sector and length for each run.

Thanks. Had a horrible feeling it was going to involve C.

Don't suppose anyone for whom C programming is their first love fancies coming up with something which when given the ID of a Part file returns the sectors & lengths?

Jamie
01-23-2005, 12:43 PM
Thanks. Had a horrible feeling it was going to involve C.

Don't suppose anyone for whom C programming is their first love fancies coming up with something which when given the ID of a Part file returns the sectors & lengths?I could do that pretty easily. But it's not quite clear to me what you have in mind. Aren't you going to have to write C code to do the necessary burst ioctls?

Jdiner has already said (http://www.dealdatabase.com/forum/showpost.php?p=200617&postcount=253) he'd support burst mode in tytools when "the time is right".

sanderton
01-23-2005, 02:07 PM
I was thinking of kludging something together with the test files which jafa has already posted - if I understand them right, then they can extract the video based on sector addresses - but if jdiner's going to build it in to TyTool I won't bother.

bhorstkotte
03-06-2006, 03:34 PM
Anyone know what ever happened with the burst mode drivers? Even on the silicondust forums, looks like the experimental drivers have been removed.

chachi
03-08-2006, 07:20 AM
Anyone know what ever happened with the burst mode drivers? Even on the silicondust forums, looks like the experimental drivers have been removed. Jafa told me there was little interest in uptake or incorporation by otheres so he binned any further efforts.

bhorstkotte
03-10-2006, 04:05 AM
Thanks chachi, kinda what I figured

laserfan
03-28-2006, 12:16 PM
Jafa told me there was little interest in uptake or incorporation by otheres so he binned any further efforts.Pisses me off--I bought a cachecard on the promise of the burst mode! :mad:

Phlbbt to jafa!

chachi
04-04-2006, 03:38 PM
well I mean it works just fine as it is and there was a buildin for mfs extraction to generate the burst cmds so not much more for Jafa to do really if no one else wanted to do any further development ...

rc3105
04-04-2006, 08:24 PM
well I mean it works just fine as it is and there was a buildin for mfs extraction to generate the burst cmds so not much more for Jafa to do really if no one else wanted to do any further development ...
hrm, lesse

basic cachecard burstmode extraction source was posted ages ago & has allready been incorporated into tridge's open source vplay utils (that Jamie has adopted/updated/optomized)

tytool/tystudio/mfs_ftp/tyserver/<whatever> would handle ty/tmf normally once they're on the pc

writing a pc side app to pull ty/tmf from tivo->pc is a few hours work tops ( guess how I know ;) )

9th tee is making $$$ off cachecards so it would be reasonable to expect them to provide a basic extraction util - could be as simple as a tivoweb module that sends a burstmode java client to the pc before each transfer

ciper
07-15-2006, 05:48 PM
Im officially showing interest.

huntercr
09-01-2006, 11:39 PM
Well, I don't know why Jafa never responded to me when I asked very politely on his forum to get the source code.

What the heck was the point of ceating the feature if he didn't at least release a protocol description?

rc3105, can you point me to the source code you're talking about? I'v searched and not found it. I must be searching the wrong terms.

huntercr



hrm, lesse

basic cachecard burstmode extraction source was posted ages ago & has allready been incorporated into tridge's open source vplay utils (that Jamie has adopted/updated/optomized)

tytool/tystudio/mfs_ftp/tyserver/<whatever> would handle ty/tmf normally once they're on the pc

writing a pc side app to pull ty/tmf from tivo->pc is a few hours work tops ( guess how I know ;) )

9th tee is making $$$ off cachecards so it would be reasonable to expect them to provide a basic extraction util - could be as simple as a tivoweb module that sends a burstmode java client to the pc before each transfer

rc3105
09-02-2006, 03:35 PM
Unified mfs_* tools (originally tridge vplay) (http://www.dealdatabase.com/forum/showthread.php?t=39487)

huntercr
11-08-2006, 10:42 PM
Unified mfs_* tools (originally tridge vplay) (http://www.dealdatabase.com/forum/showthread.php?t=39487)

OK I have the source code for this, but it still only provides the way to get the appropriate burst command line. It doens't define the actual burst protocol as far as I can tell anywhere in the source code.

You still have to use the burst.exe program that he wrote on the client side, which is not a good solution ( especially since I am not even using a windows machine )

Am I looking at this wrong here? The only thing mfs_* tools seems to be able to give you is the sectors for the FSIDs. We have to feed that to the burst daemon somehow, and there seem to be no instructions on how to do that.

please be patient with me. I know I must be thinking about this the wrong way somehow.

crh

Jamie
11-09-2006, 12:50 AM
OK I have the source code for this, but it still only provides the way to get the appropriate burst command line. It doens't define the actual burst protocol as far as I can tell anywhere in the source code.Right. The burst protocol and driver interface was never documented.