[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Digest Response Lag Revisited
The digests I get are currently around 40,000 bytes.
I assume this means that some logic exist saying,
"when 40,000 bytes has accumulated, send a digest"
Phil's thoughts several weeks ago about the Digest and delayed
responses to threads got me thinking. Additionally, I noticed
this weekend that I did not get many digests, indicating
sparse list traffic (nice weather?), so the amount of time
that was captured in an individual digest was a considerable.
First, is 40,000 bytes too large a criteria for sending a
digest, resulting in more time delay for digest users? A
smaller criteria, say 20,000 bytes, would double the number of
digest received, but reduce the time lag for digest users.
Second, in order to keep the digest more up to speed with
threads when list traffic is sparse, would there be any
advantage to changing the logic by adding OR and IF statements
with some time criteria? For example,
"when 20,000 bytes has accumulated, OR 2 hours has passed, IF
more than 5,000 bytes has accumulated, send a digest"
Any time from 1 to 8 hours would makes sense, depending on the
message volume tolerable to digest users. I know that the
reason I use the digest is to reduce the number of messages I
get, since I use a work account and do not need the extra
traffic. The 'OR' statement I described above would still
reduce the number of messages for digest users like me
compared to the non-digest list, albeit using a few more
digest than we do now. Say we chose to use the logic I
described above. This might result in 10 to 20 digest per day
if at least 5,000 bytes was ready to go every 2 hours,
possibly less if dead periods existed with less than 5,000
bytes and possibly more if 2 hour periods occurred with more
than 40,000 bytes.
Is 10-20 digest per day too much traffic for some digest
users? What is the preferred maximum number of messages per
day for digest users?
Eric R. Kissell
1986 5000cstq, 1.8 bar