Hi Andrew,

 AL> >> One of the other sysops in our net released a cost table for
 AL> >> D'Bridge. The interesting thing is that D'Bridge allows different
 AL> >> costs for different days and times. It would =really= be nice to
 AL> >> have something similar for Binkley.

 IS> Do you mean something like ..
[..]
 IS> Event Week     18:00 22:00   B C L<37  T=2,12       E2=5 E3=7 ;
 IS> Evening 66%
 IS> Event WkEnd    18:00 22:00   B C L<60  T=2,12       E2=5 E3=7 ;
 IS> Sat/Sun 40%

 AL> No.  D'Bridge can be configured to calculate the cost of
 AL> each call based upon the time of day/day of week.  For
 AL> example, you can tell it that it costs $0.23/minute to call
 AL> a number during the day weekdays, but only $0.11/minute at
 AL> night or on weekends.

That's pretty well what I've managed to program into my events, above.  My
'100%', '66%' and '40%' comments refer to the percentage of full-rate cost
at different times of day / days of week.  In other words, I'm only calling
more expensive nodes at the cheapest times, allowing mid-cost calls at
slightly more expensive times, and only call near-local nodes during
daytime rates.

We have the added complication here of a fixed 'flagfall' of 10-12c for LD
calls, then charging at so much per second, so Binkley's per-flat-minute
charging is of limited utility.  Nor is the Eurocost variant much closer to
our system, so logged costs aren't very indicative at all.  We also have
untimed local calls, at a fixed charge (20-25c), but which I have set to 0
in my compiled nodelist, to facilitate L=0 local calling at any time.

Further, I have my regular echomail links compiled to a lower cost, like
15c, which is more indicative of the true cost at the (economy) times that
I tend to call these.  Along with a bit of packer scheduling to hold or
crash mail at the right times, it works well enough, but takes a bit of
care to set up.

 AL> With Binkley, only one cost per node is supported (the
 AL> value that your nodelist compiler places into the nodelist
 AL> indexes).

Yes, but you know the time breaks that your local phone company uses, no?

I take your point about the possible conveniences of finer cost control,
but by the time you take different systems used in different parts of the
world into account, it gets tricky.  From my own earlier small efforts on
this, I suspect that sending anything less than fully working C code that
implements it differently, is more than likely just whistling in the wind
..

Regards, Ian

--- MaltEd 1.0.b5