On Sat, Aug 18, 2012 at 2:33 AM, Gunnar Hellström <[email protected]> wrote: > On 2012-08-18 05:15, Mark Rejhon wrote: >> >> (for <t/>) >> >and Basic Real-Time Text (whenever <e/> is otherwise needed). A major >> >potential implementer has indicated they prefer this method for >> >simplicity (low CPU overhead compared to section 6.4.1 "Avoid Bursty >> >Text Presentation"). > > Mark, this is a side question, not influencing the <e/> discussion. > What is your proposal to this potential major implementer to make real-time > text usable when only using 'reset' and not using <w/>. > > Do you recommend to use a shorter interval than 700 ms? The earlier > documented usability limit is 500 ms. Above that, the users start thinking > jerkiness is unpleasant, and in reality 300 is experienced as more pleasant > than 500. > -But we have said that 300 ms might cause too much load on servers or > networks to be a universally used interval. > > Or do you recommend to use time smoothing (displaying received characters > progressively during the transmission interval ) instead of key-press > intervals? > -But you have said that time smoothing may be cpu consuming and is > complicated to introduce on the receiving end in modern xml library > environments. > > I hope they do not want to have annoyed users experiencing 700 ms jerks in > their text conversation.
(This is talking about Transmission Intervals) http://xmpp.org/extensions/xep-0301.html#transmission_interval I'm interested in hearing XSF's opinion about intervals. They are a compromise balance. 700ms allows about 300ms of 'headroom' (network latency) to meet the 1 second (700+300 = 1000) end-to-end latency specified by ITU-T F.700 (section 2.1.2.1, IIRC) 700ms with key press intervals being preserved, often looks better than 300ms without key press intervals. They can also be roughly similar (total) bandwidth, since key press intervals makes message stanzas significantly larger. Now, I can say my tests have shown that 100ms intervals is nearly always as reliable, but I've seen problems with a slow-performing XMPP network when sending ten stanzas per second. So that's probably too low, but I definitely don't ban that because I only use "SHOULD" terminology with the 700ms and the 300ms-1000ms ranges I've mentioned. So there's room for high-performance local XMPP networks with 0ms intervals (e.g. instant transmit of every keypess), all the way to the other gamut of slow low-rate 9600bps Iridium satellite transmission at 2500ms interval (though that's more "NEAR real-time" not "true real-time") All that said, I have no objection to implementers choosing to do 500ms instead of 700ms, and I wouldn't even complain if somebody decided to be daring and used 100ms by default for their network. But should 500ms be the default? I need many opinions before changing 700 to 500. Mark Rejhon
