Hi Walter,
one part of your message I will answer on the mailing list, another one (that
with the telephone company) comes private to you.
Walter Haidinger wrote:
>
> Hi!
> Thanks for the quick reply.
>
> On Tue, 28 Jul 1998, Thomas Michalka wrote:
>
> > > For me, diald logs the duration of the connections incorrectly. It seems
> > > to me that the timer is started/stopped when the ppp link comes up/down.
> Now for a quick overview:
>
> 1) Manually timed: 706 seconds offset: 0
> 2) file in (dis)connect 711 seconds offset: +5
> 3) diald log 686 seconds offset: -20
> 4) ppp link uptime 682 seconds offset: -24
>
> The offset 1)-2) was the time diald took to run the connect/disconnect
> scripts. (My Amd486/100 was compiling...)
> Obviously, diald timings started when pppd was run: 26 seconds after the
> connect script was called.
Obviously. That's just what I told you with respect to comparison of syslog and
diald's accounting-log of mine (> > Time of "Connected to site ..." is identical
with the time of "Running pppd ...").
> Yes, but when the chat script finishes it is already too late for me.
That's because of the terminal login in your chat script which runs between the
modem's CONNECT (impulse start in germany) and the point of time when diald
starts to run pppd.
> The modem is off hook for the whole duration of the chat command, time
> for which I'm charged.
No, but from that moment when it receives the "ATDT<ISP number>" from the chat
program. This is after some initialization in the chat script. Then normally it
takes 3 to 5 seconds for establishing the physical link which the modem
announces with CONNECT.
> > > Unfortunately, the modem takes about 20 seconds to establish the link to
> > > my ISP.
Once again, not the modem, as I explained, but the terminal login in the chat
script.
> > Or do you mean after the modem has physically connected - the negotiation phase
> > of pppd?
> The 20 seconds regard *only* the chat script in which I need to send
> username and password too.
Sorry, now I see you were clear about what the 20 seconds are caused of.
> > [BTW: do you use a conventional terminal login procedure? Authentication via PAP
> > could shorten the process, I suppose.]
> Yes, I mailed my ISP about that. However, dialing in won't work without
> username/password despite using CHAP for ppp. Let's wait for an reply...
Seems to me as a double login procedure, but:
CHAP is used to transmit username/password unreadable for third party. If you
*have* to transmit both with the chat program before, CHAP would be of no sense.
So if you can login via CHAP you shouldn't need a terminal login before.
And, in consequence, this would be the solution for all your problems (hope the
currently discussed are the only one ;-), because CHAP (and PAP too) runs within
pppd, which is started immediately after chat has finished with getting the
modem's CONNECT.
So the time span between the beginning of the impulse and logging the link
uptime would shorten to parts of a second.
> [...]
> To clearify things a bit, the last lines of my chat scripts:
> OK ATDT$TELEPHONE \
> CONNECT '' \
> ogin:--ogin: $ACCOUNT \
> assword: $PASSWORD
>
> An impulse actually starts when the modem receives a 'CONNECT'.
Yes, now you have fully clearified it ( at last you told me: "The first
[impulse] is charged when the modem goes off hook and begins to dial."
- the fact in the old analog phone net you mentioned anywhere.)
> However, I still need to transmit my username and password which takes
> obviously takes some time.
Sorry again, for anticipating you.
> Because I am unable to distingiush when the ISP's modem goes off hook,
You just told that the impulse begins when *your* modem sends a CONNECT to
*your* computer, so why do you have to know anything about when your provider's
modem behind the branch goes off hook?
When your ISP's branch takes over your call, your modem will say CONNECT, *not*
when the ISP's modem hookes off.
> I tend to measure connect time from the beginning of the chat script.
Yes, this way you loose about 20 seconds of an impulse but the longer a session
is the easier you can carry the loss.
> Exact timings would use the time of the
> moment CONNECT is received. Because of tone dailing, it seems to me that
> login and password need the majority of the time (>15 secs).
Just my statement above.
> I just want to make sure that I'm _ahead_ of the impulse start.
With a CHAP (or PAP) login the start of pppd will be nearest to impulse start, 1
second later at most (a fuzz time of 10 seconds in the impulse option would then
let diald shut down the link in time).
> > > One full impulse is 120 seconds. Due to the initial delay I have to
> > > shorten the first impulse by 20 seconds to, after the first impulse, be in
> > > sync with the phone company again.
>
> > Then, I think, it should be "impulse 100,100,20"
> > (dial_time 20s + first_fix_time 100s = first_impulse 120s), shouldn't it?
>
> Hhm. Isn't the fuzz time applied for the first impulse?
If there hasn't changed something, I think not.
> Is there a difference between 'impulse 100,100,20' and 'impulse 100,20' ?
Yes there is.
The first expression tells diald:
First keep the link up for 100 sec, then 100 sec furthermore, and then probe the
link 20 sec for idle state.
The second expressions means:
First keep the link up for 100 sec, and then probe the link 20 sec for idle
state.
Impulse with three arguments is useful if the first impulse of a link is longer
than the following ones (yes, there are companies whom you pay a minimum fee for
a longer first impulse, e.g. mobile communication providers).
> I do not think so.
> As I understood it, impulses are <initial+fuzz> and thereafter
> <secondary+fuzz>. That is
> 80+20=100 (20 second delay) and
> 100+20=120 (a full impluse).
> Am I getting something wrong here?
I run diald in version 0.14., and if there hasn't changed s.th. in a later
version, that you might use, I think you might have got this stuff wrong.
> > If you want to block the link now, just block it at once. If you can wait for
> > the end of the current impulse you can block it anytime after diald shut the
> > link down (that's it what diald does with an idle link at the end of an impulse
> > ;-)
> This only works if there is no traffic anymore.
Yes, I agree. That's it what I got wrong. Thanks.
> Think of a cron job that
> starts 30 seconds before the impulse ends. This would keep the link up for
> some time (imagine a rule of 60 seconds), probably into the next
> impulse.
> I am missing an option which downs the link before a new impulse starts
> *regardless* of the link traffic. Thus providing maximum online time with
> no _additional_ cost.
Why? Wouldn't you like diald to keep the link up while it is active? Otherwise
your cron job (at night) would not succeed.
If your cron job finishes regularly diald won't keep the link up longer than the
current impulse lasts. Thus you won't have additional costs.
> > You can "restrict" (see the keyword) several different impulses to different
> > times of the day or days of the week or the month and further on.
> That does not solve the problem of wasting parts of an impulse when
> issuing the 'block' command.
Can you really not carry the wasting of a few seconds, while no more traffic
passes the link?
You won't pay parts of the unit fee if the link goes down (immediately after the
last traffic) before the impulse actually finishes.
BTW: I now remember that you *can* force the link down with no regard to the
link traffic (but also not to the impulse):
echo down > /etc/diald.fifo
Best regards, Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
