Subject: Re: [dtn-users] Improving performance in DTN2

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 09:25:01 -0500

Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've been working in a vacuum. We've been working on implementing Aggregate Custody Signals (ACS) in the DTN2 source code so that we can catch up with the ION version updated by the University of Colorado at Boulder and get back into the DTN network with their experiments. As I've been in the DTN2 source code, I have also been working on improving the throughput with the goal of streaming video via DTN. I am currently working on an ACS patch to submit for the reference implementation and am including some of the performance enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte payload] per second through two DTN nodes with custody transfer and ACS processing. It processed 13,605,622 bundles and only lost 6 frames on the front end [missed UDP packets that never made it to the receiver that feeds the first DTN node] which were probably not related to the DTN node's performance. This is using the reference implementation with the ACS patches. In memory, the dtnd process has grown to 2.1GB due to timers that have been canceled but have not yet expired since I use a 24 hour expiration time. I have a reaper thread that periodically clears the canceled timers that I was not planning on including in the ACS patch since it requires a coordinated update to the oasys package but I think I'll go ahead and include it seeing that there is an interest.

On my development machine, our in-house version tops out at about 340 bundles/second and I haven't tested the patched reference implementation to that extent. Our in-house version has more extensive infrastructure changes that may not be suitable for a reference implementation since the goal was performance for our needs and some of the changes may have broken some of the nuances of the BP specification which I have not studied in depth. We'll check to see if there is a way to make it available to the community for evaluation as there may be some mods that can be cherry picked for adapting into the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configuring both oasys and dtn2 but I haven't bothered to do that yet as the debug is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: Input, Output, Storage, ACS and everything else in the original BD thread. The BD currently manages the oasys::TimerSystem which I changed to crank up the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles but I just saw that I used a std::map instead. I'll have to go back and change that. Anyway, std::map is better suited for this than the std::list and a change to std::multimap should be even better to allow detection and retention of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expire which keeps freed bundles from being removed as well as the timers. I use a reaper thread to periodically remove the canceled timers from the oasys::TimerSystem but I think adding an overridable onCancel() method to the oasys::Timer class would be good way to trigger processing that could free the bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it takes to add a bundle to the database. I changed the payload directory structure to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to delivered so they don't get deleted until they expire. Minor unless you have tons of custody signals hanging around but the leaner the memory usage the better :)

Hope this helps,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 29 Jun 2012 09:35:07 -0500

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:

Angela,
I just joined the dtn-users mailing list yesterday and discovered that I’ve been working in a vacuum. We’ve been working on implementing Aggregate Custody Signals (ACS) in the DTN2 source code so that we can catch up with the ION version updated by the University of Colorado at Boulder and get back into the DTN network with their experiments. As I’ve been in the DTN2 source code, I have also been working on improving the throughput with the goal of streaming video via DTN. I am currently working on an ACS patch to submit for the reference implementation and am including some of the performance enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte payload] per second through two DTN nodes with custody transfer and ACS processing. It processed 13,605,622 bundles and only lost 6 frames on the front end [missed UDP packets that never made it to the receiver that feeds the first DTN node] which were probably not related to the DTN node’s performance. This is using the reference implementation with the ACS patches. In memory, the dtnd process has grown to 2.1GB due to timers that have been canceled but have not yet expired since I use a 24 hour expiration time. I have a reaper thread that periodically clears the canceled timers that I was not planning on including in the ACS patch since it requires a coordinated update to the oasys package but I think I’ll go ahead and include it seeing that there is an interest.

On my development machine, our in-house version tops out at about 340 bundles/second and I haven’t tested the patched reference implementation to that extent. Our in-house version has more extensive infrastructure changes that may not be suitable for a reference implementation since the goal was performance for our needs and some of the changes may have broken some of the nuances of the BP specification which I have not studied in depth. We’ll check to see if there is a way to make it available to the community for evaluation as there may be some mods that can be cherry picked for adapting into the reference implementation.

In the meantime, here are some things we’ve run across:

* You might gain improvements using the--disable-debug option when configuring both oasys and dtn2 but I haven’t bothered to do that yet as the debug is still useful to me

* BundleDaemon is a single thread. I’ve broken this into multiple threads: Input, Output, Storage, ACS and everything else in the original BD thread. The BD currently manages the oasys::TimerSystem which I changed to crank up the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles but I just saw that I used a std::map instead. I’ll have to go back and change that. Anyway, std::map is better suited for this than the std::list and a change to std::multimap should be even better to allow detection and retention of duplicates if so configured.

* I’m using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk – the more files in the directory the longer it takes to add a bundle to the database. I changed the payload directory structure to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to delivered so they don’t get deleted until they expire. Minor unless you have tons of custody signals hanging around but the leaner the memory usage the better :)

Hope this helps,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-users

---

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 09:55:10 -0500

This is using static routes over IP with no disconnection. The Aggregate Custody Signals are configured for 30 seconds, so every 30 seconds the first node takes a hit while it is releasing about 5000 bundles from custody. Ingest stops for a second or so and then as it catches up it processes at about 400 bundles per second.

David Zoller
COLSA Corporation

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-users] Improving performance in DTN2

- Will Ivancic

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

---

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 10:21:21 -0500

Bob,
I like to lurk in the background but you may have run across Lee Pitts as he is my front man :)

I just completed applying the patches to the latest sourceforge version yesterday morning and fired it up so I don't have long term results yet. I'll let it run over the weekend and check the memory usage. I believe that it will stabilize as I did run some valgrind testing (on our version) and most of the accumulating memory was due to timers and bundles not getting freed until expiration. I did fix one memory leak (fixed in the patch) but can't say positively that there is not another lurking in there somewhere.

The std::multimap change would help some but not too much in this particular test since the pending bundle list never grows beyond 5000 bundles. It would significantly help in the tests proposed by Will as the disconnects would result in lots of bundles accumulating in the first node.

We will be doing further testing with at least a 4-node architecture in the future.

Thanks and best regards,
DZ

David Zoller
COLSA Corporation

From: Durst, Robert C. [mailto:[email-masked]]
Sent: Friday, June 29, 2012 9:37 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: RE: Re: [dtn-users] Improving performance in DTN2

David,

I don't think I know you, but this is awesome.  Thanks!

Do you have a sense of whether, after 24 hours, memory usage would stabilize (under constant load)?  Any plans to do a more extended test?  Also, do you have a sense of whether the change to use std::multimap will positively affect the bundle throughput rate?  Finally, is there any need, desire, plan to do a three- (or more) node test?

This is great work in understanding what needs to be done to use DTN2 in a "production" context.  Thanks for sharing it.

Best regards,
Bob Durst
The MITRE Corporation

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Friday, June 29, 2012 10:25 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-users] Improving performance in DTN2

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

---

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 10:32:54 -0500

I'm sure this implementation will bog down during the disconnects as bundles accumulate in the pending queue which impacts the find_duplicate() mentioned below but I'll try to squeeze in some testing for you some time. What routing do you use for the disconnects or should I  just pull the network cable?
DZ

David Zoller
COLSA Corporation

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performance in DTN2

Add disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.

- Will

On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:

David Zoller
COLSA Corporation

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

- Will Ivancic

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: "Pitts, Robert L. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 10:50:17 -0500

Bob,

                David has been working the DTN project with me at MSFC as part of NASA's project.   Our first implementation was with 2.7 and when we decided to step-up and do ACS and supported the DTN video at CCSDS we knew we had to do better.  This was done with some MSFC management funds as well as with the DTN project.  David's extensions are making our deployment this fall much less risky.

Lee

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Friday, June 29, 2012 10:21 AM
To: Durst, Robert C.
Cc: [email-masked]
Subject: Re: [dtn-users] Improving performance in DTN2

Bob,

Thanks and best regards,
DZ

David Zoller
COLSA Corporation

From: Durst, Robert C. [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, June 29, 2012 9:37 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: RE: Re: [dtn-users] Improving performance in DTN2

David,

Best regards,
Bob Durst
The MITRE Corporation

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

---

From: Jim Wright <[email-masked]>
Date: Fri, 29 Jun 2012 11:31:54 -0600

David, Wireshark 1.8 has just been released. It contains enhancements to the Bundle Protocol dissection that I added recently. The main focus of the work was adding the ability to handle ACS, CTEB and ECOS. Hope this helps!

Jim Wright
BioServe Space Technologies
[email-masked]<mailto:[email-masked]>
303-492-1579

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 29 Jun 2012 12:37:20 -0500

You can disconnect in a number of ways:
netem
pull cable (but not very repeatable timing wise)
modify ip-table script or link up/down script (probably the easiest and causes the least strain on the CPU).
put a channel emulator in between DTN nodes.

The point is, you're streaming in a disconnected environment otherwise there is no reason to use DTN.  So you need to test the storage, not just the forwarding.

You probably should also put in some other bundle source/destination pairs with various lifetimes.

You need to see where it breaks and how fragile (or not) the system is.  Tuning a configuration to get something to work is just the start.

- Will

On Jun 29, 2012, at 11:32 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:

I’m sure this implementation will bog down during the disconnects as bundles accumulate in the pending queue which impacts the find_duplicate() mentioned below but I’ll try to squeeze in some testing for you some time. What routing do you use for the disconnects or should I  just pull the network cable?
DZ

David Zoller
COLSA Corporation

- Will

David Zoller
COLSA Corporation

- Will Ivancic

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

---

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 13:08:31 -0500

Angela,
Thanks and good questions...

1) I believe the 340 bundles/second is the API performance rather than the network performance. I have an app on the front end which reads a socket and passes the data as a payload to the dtn_send() method on the first node. The counter increments after each return from the dtn_send() call. On the back end of the other node, I have the counterpart app (similar to dtnsink) which accepts delivery of bundles as fast as it can and reports its bundles/second.

Thinking about it , when I said that it "tops out", I really mean that the input rate to the first node is sustained fairly smoothly at that rate. If I take the rate higher, then the input rate gets choppy and UDP packets get dropped (I have a sequence counter in the data). This was just an informal run out of curiosity, and as I recall, the output from the second node was probably pretty choppy. The second system does not perform as well as the development system so I don't know if it was the culprit or if there are some inefficiencies in the output side of the first node.

Before too long, I'll be able to set up tests with 4 similar systems. I can see that there are a lot of variations and quantifying to be done and so few hours per day :)

2) Thanks for pointing out the --disable-debug-memory option. After finding the first, I hadn't thought to look for others.

3) The "multi-threaded BundleDaemon" will not be part of the ACS patch as that is what I think might introduce some non-conformant behavior. One for instance, a colleague told me that he tested the reference implementation using two opportunistic routes for an EID and found that it only delivered bundles on the first route even though both were available which is what he wanted. I have not tried it but I think that this behavior would be changed and the bundles would be delivered to both routes. I have not dug into the spec to determine the correct behavior. 

4) find_duplicate - The map/multimap will not be part of the ACS patch because that starts snowballing into pulling in additional changes needed it to support it. I use the GbofId  string as the key into the map so there is no need to iterate through the list to see if the bundle is in it. 

5) When a bundle is added to the BundleStorage, everything but the payload is actually stored in the database. The payload for each bundle is written to disk in its own file in the $dbdir/bundles directory in the default configuration. The more files there are in that bundles directory, the longer it takes the operating system to open a new file in it. On my system, I was able to detect noticeable slowdown when there were around 15-20,000 files. I changed the BundlePayload to write the first 10000 payloads to $dbdir/bundles/0/,  the next 10000 in $dbdir/bundles/1/, etc.

I was not planning on including the directory changes in the ACS patch but it is pretty self-contained and not too difficult to add. 

I'm not sure who makes the call as to what ends up in the official reference implementation but you have my condolences. :)
DZ

David Zoller
COLSA Corporation
HOSC / M103  
/Office: (256) 544-1820
(EMail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 29, 2012 11:38 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: Ivancic, William D. (GRC-RHN0); [email-masked]; [email-masked]
Subject: RE: [dtn-users] Improving performance in DTN2

David,

Thanks very much for all the information! That would be great if you're able to release some of the performance improvements as part of the patch.
 If you don't mind, I have a few questions/comments:

You mentioned that DTN2 tops out at about 340 bundles/second. What exactly are you measuring here? Is it just the network throughput, or are you also measuring the API performance?

We also found that the --disable-debug-locking flag helps with performance, as well as the --disable-debug-memory flag.

I don't quite understand how you made BundleDaemon into multiple threads, will this be part of the code release you mentioned?

That's interesting that you mentioned BundleDaemon::find_duplicate. That function showed up in our profile testing as well. I rewrote that as a hash map and it made a little difference, about 5% if I remember correctly. I'm not quite sure how a multimap would be better here, could you explain this a little more? And will this be part of the code release as well?

You're note about custody timers is really interesting, this isn't something we looked at, so I'll have to spend some time looking into this.

I'm also confused about the payload directory structure you mentioned, could you describe this a little more as well?

Thanks again for all the info, it's great to hear other people are interested in this as well!

-Angela

Agnela Hennessy
Laboratory for Telecommunications Sciences (LTS)
301-422-5287

> This is using static routes over IP with no disconnection. The 
> Aggregate Custody Signals are configured for 30 seconds, so every 30 
> seconds the first node takes a hit while it is releasing about 5000 
> bundles from custody. Ingest stops for a second or so and then as it 
> catches up it processes at about 400 bundles per second.
>
> David Zoller
> COLSA Corporation
> I just joined the dtn-users mailing list yesterday and discovered that 
> I've been working in a vacuum. We've been working on implementing 
> Aggregate Custody Signals (ACS) in the DTN2 source code so that we can 
> catch up with the ION version updated by the University of Colorado at 
> Boulder and get back into the DTN network with their experiments. As 
> I've been in the DTN2 source code, I have also been working on 
> improving the throughput with the goal of streaming video via DTN. I 
> am currently working on an ACS patch to submit for the reference 
> implementation and am including some of the performance enhancements in it as a bonus.
>
> I just concluded a 22 hour test piping 167 frames[bundles with a 1316 
> byte payload] per second through two DTN nodes with custody transfer 
> and ACS processing. It processed 13,605,622 bundles and only lost 6 
> frames on the front end [missed UDP packets that never made it to the 
> receiver that feeds the first DTN node] which were probably not 
> related to the DTN node's performance. This is using the reference 
> implementation with the ACS patches. In memory, the dtnd process has 
> grown to 2.1GB due to timers that have been canceled but have not yet 
> expired since I use a 24 hour expiration time. I have a reaper thread 
> that periodically clears the canceled timers that I was not planning 
> on including in the ACS patch since it requires a coordinated update 
> to the oasys package but I think I'll go ahead and include it seeing that there is an interest.
>
> On my development machine, our in-house version tops out at about 340 
> bundles/second and I haven't tested the patched reference 
> implementation to that extent. Our in-house version has more extensive 
> infrastructure changes that may not be suitable for a reference 
> implementation since the goal was performance for our needs and some 
> of the changes may have broken some of the nuances of the BP 
> specification which I have not studied in depth. We'll check to see if 
> there is a way to make it available to the community for evaluation as 
> there may be some mods that can be cherry picked for adapting into the reference implementation.
>
> * You might gain improvements using the--disable-debug option when 
> configuring both oasys and dtn2 but I haven't bothered to do that yet 
> as the debug is still useful to me
>
> * BundleDaemon is a single thread. I've broken this into multiple threads:
> Input, Output, Storage, ACS and everything else in the original BD thread.
> The BD currently manages the oasys::TimerSystem which I changed to 
> crank up the oasys::TimerThread to offload that work.
>
> * BundleDaemon::find_duplicate() bogs down significantly as you 
> approach
> 15,000 bundles in the pending_bundles_ list.
>      !!Ha!! My intent was to use a std::multimap for the pending 
> bundles but I just saw that I used a std::map instead. I'll have to go 
> back and change that. Anyway, std::map is better suited for this than 
> the std::list and a change to std::multimap should be even better to 
> allow detection and retention of duplicates if so configured.
>
> * CustodyTimers do not release the reference to the bundle until they 
> expire which keeps freed bundles from being removed as well as the timers.
> I use a reaper thread to periodically remove the canceled timers from 
> the oasys::TimerSystem but I think adding an overridable onCancel() 
> method to the oasys::Timer class would be good way to trigger 
> processing that could free the bundle reference and allow the bundle to be freed quicker.
>
> * Payload storage to disk - the more files in the directory the longer 
> it takes to add a bundle to the database. I changed the payload 
> directory structure to a tiered layout with 10,000 bundle payload per directory.
>
> * AdminRegistration and PingRegistration do not update the bundle 
> fwdlog to delivered so they don't get deleted until they expire. Minor 
> unless you have tons of custody signals hanging around but the leaner 
> the memory usage the better :)
>
> Hope this helps,
> DZ
>
>
> David Zoller
> COLSA Corporation

---

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 13:19:04 -0500

Awesome! Thanks, Jim, I will be downloading a copy very shortly as that will definitely be useful.

David Zoller
COLSA Corporation

From: Jim Wright [mailto:[email-masked]]
Sent: Friday, June 29, 2012 12:32 PM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: Durst, Robert C.; [email-masked]
Subject: Re: [dtn-users] Improving performance in DTN2

Jim Wright

---

From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Fri, 29 Jun 2012 13:37:13 -0500

Will,
Good point. I've got my blinders on as I'm the ground receipt node for a downlink and the nodes I transmit to are almost always online. I'll have to expand my horizons and testing. A script should be no problem. I've heard tidbits of being able to schedule connect times for nodes and suspected that there might be a router type that implemented a schedule but haven't taken the time to research it yet and thought you might have been referring to that for the disconnects.
Thanks,
DZ

David Zoller
COLSA Corporation

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 12:37 PM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: [email-masked]
Subject: Re: [dtn-users] Improving performance in DTN2

- Will

David Zoller
COLSA Corporation

- Will

David Zoller
COLSA Corporation

- Will Ivancic

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 29 Jun 2012 14:06:42 -0500

If your talking ION than contact graph routing (CGR) is there. As a first order approximation, you can of think of CGR as dynamic static routing (but it is a quite a bit more than that). In CGR you basically schedule contact times as would be done in predictive contacts such as space system (Orbital Dynamics).  With CGR  you could tell the system when to send and stop  as a way to emulate disconnection.

I do not believe CGR is implemented in DTN2.

- Will

On Jun 29, 2012, at 2:37 PM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:

Will,
Good point. I’ve got my blinders on as I’m the ground receipt node for a downlink and the nodes I transmit to are almost always online. I’ll have to expand my horizons and testing. A script should be no problem. I’ve heard tidbits of being able to schedule connect times for nodes and suspected that there might be a router type that implemented a schedule but haven’t taken the time to research it yet and thought you might have been referring to that for the disconnects.
Thanks,
DZ

David Zoller
COLSA Corporation

- Will

David Zoller
COLSA Corporation

- Will

David Zoller
COLSA Corporation

- Will Ivancic

Angela,

Hope this helps,
DZ

David Zoller
COLSA Corporation

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jun 2012 22:41:01 +0100

If you use the LTPCL via LTPlib you can also do that and we've
gotten interop with ION working here.

(Having said that, my LTPlib code's pretty crap so might mess
up any performance. OTOH, if you're in the mood for fixing things...:-)

S

On 06/29/2012 08:06 PM, Ivancic, William D. (GRC-RHN0) wrote:
> [email-masked]