Re: [EPIC]notify interval proposal
On Monday 03 February 2003 7:27 am, [EMAIL PROTECTED] wrote: having finer granularity doesn't necessarily mean that it would be used to have notify interval shorter than 60 seconds. it would also allow notify intervals of, for example, 90 seconds. there still might be a lower limit of 60 seconds. Correct me if I'm wrong, but the impression I got from nsx on IRC and in his mail was that he wanted a notify interval of less than 60 seconds, which is what I'm discussing here. I wouldn't have any problem with allow more than +-60 second precision. Regards, Edward. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On Mon Feb 03, 2003; 12:48PM + Edward Brocklesby propagated the following: On Monday 03 February 2003 7:27 am, [EMAIL PROTECTED] wrote: having finer granularity doesn't necessarily mean that it would be used to have notify interval shorter than 60 seconds. it would also allow notify intervals of, for example, 90 seconds. there still might be a lower limit of 60 seconds. Correct me if I'm wrong, but the impression I got from nsx on IRC and in his mail was that he wanted a notify interval of less than 60 seconds, which is what I'm discussing here. You are correct. Personally I'd like to see this tuneable down to 20-30 seconds (at lowest). It would be nice to have a more precise notify level. I also think that if servers find this load burdensome than they should either add code to disconnect users who do this or add WATCH support, both of which are fairly trivial things to do. I wouldn't have any problem with allow more than +-60 second precision. Regards, Edward. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list -wd -- chip norkus; unix geek and programmer; [EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
nsx said: Yes, I am campaigning for both better precision, and a change of the lower notify interval limit. I suppose they sort of go hand in hand, since to either abolish or lower the lower limit, you'd probably need to provide better precision anyway. Kev said: Personally, I don't see the problem with the first part--increasing the precision. As for a lower limit, I would strongly suggest that it should not be less than 30 seconds. It seems that the current compromise solution seems to be acceptable to a large number of people: * Remove NOTIFY stuff from the top_of_minute timer, into a second timer. * Allow user to modify timeout interval of that second timer via /SET NOTIFY_INTERVAL * Add a #define in config.h which will set an absolute minimum value of /SET NOTIFY_INTERVAL, so that the user can be assured that a script will not set a value lower than they wish to have. * The default value of this #define will be 60 for backward compatability. Of course with every compromise, not everybody got everything they wanted, but this seems to be very much in the middle of what everybody hoped for. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
Edward Brocklesby wrote: [snip] and I'm not likely to talk to someone who's here for 30 seconds and then gone again [snip] -larne. Try using dial-up service over the US's PSTN. ;) -- Ben msg00259/pgp0.pgp Description: PGP signature
Re: [EPIC]notify interval proposal
Normally I would not follow up to a request for discussion, but nsx asked me to share why I believe in the status quo. The entirity of this message is not a statement of policy or rules or anything of the sort with regard to epic. It simply states my personal opinions as an epic user, and the reasoning that prompted this discussion in the first place. Nsx said: - From what I can tell, epic doesn't allow you any more precision than minutes in the notify interval, and it refuses to accept a value of under a minute. For most of epic's life, the main focal point of everything that happens is the io() function, which i refer to as The Looper. io() has had its share of issues, particularly how everything is hardcoded into it, and that limits flexibility and generalness. One of the things that was hardcoded into the looper was top of the minute processing. At the top of every minute, epic does various housekeeping duties: 1) Checks your mail 2) Throws /on timer 3) Does your notifies 4) Updates the clock (on the status bar) Previously, EPIC always and only ever performed these duties at the top of each minute. The /SET NOTIFY_INTERVAL value was added as a way for some users, who felt that doing notifies once a minute was far too frequently and imposed too much of a burden on the server, to rachet down the frequency of their notifies. Even though the unit used was a second, the granularity was always measured in minutes, since the notifies only ever happened at most once a minute anyways. Recently, this changed somewhat. When I rewrote the /timer system, I was able to remove the top of the minute processing from the looper and instead make it a regular, recurring, system timer. Because it is now a regular, recurring, system timer, it is no longer necessarily hardcoded to happen only at the top of every minute. Nsx has pointed out that this has opened up the viability of discussing whether or not we should remove notify handling from the top of the minute processing and make it a second, separate regular, recurring, system timer with its own timeout and have it work independantly of the top of the minute timer. The reason why notify is done at most once a minute even now should be clear; it is done from within a timer that happens at most once a minute. The question then becomes, should we remove notify handling from this timer; make it operate under its own timer; and have the timeout be controlled by /SET NOTIFY_INTERVAL. This raises sticky issues however. As we all know, the server imposes flood control upon the user, generally allowing at most one protocol command per 2 seconds. Excessive commands causes the client to be penalized and eventually disconnected. In general, it would be a violation of user's expectations that changing a /SET would cause them to get disconnected from the server due to reasons that they cannot personally understand (ie, if you /set notify_interval 1, you will be disconnected eventually, the user wouldn't understand why, though). So there perhaps should be some lower limit on the number of seconds between each notify event, *even though a user may wish to do it more frequently*. The question is what that minimum number of seconds should be. My personal opinion is still that 60 seconds is best, to be most kind to the server. Notify imposes a not-small burden on the server, and much pain and suffering is caused by clients doing TOO MANY notifies, not too few... And that is my opinion. I am not speaking as a coder, but as a fellow user. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
I'd assume that most users who would set notify_interval, would know what they're doing, but I may be wrong. I can certainly see the scenario in which a new user who likes to experiment, unsuspectingly sets this to what most would consider an unreasonable value (such as 1), but I also assume even the most unfamiliar user to epic would be more cautious than that, and realize that tinkering with things without realizing their purpose can have consequences. Nonetheless, I can certainly see why Jeremy sees it prudent to enforce a lower limit here. But at the very least, I would like to see what I would consider a more reasonable lower limit (20-30 seconds, perhaps). I wouldn't consider that too unreasonable since the majority of the IRC population is probably mIRC clients, and they all use a 30 seconds interval. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
