moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00
Code Issues Releases Wiki Activity

Fix use of definition lists.

Browse Source
This commit is contained in:
Tobias Markmann 2010-10-06 00:09:10 +02:00
parent 24a1af328d
commit dee8939277
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
xep-0286.xml
View File

@ -113,27 +113,45 @@
<section1 topic='Conclusions'> <section1 topic='Conclusions'>
<p>As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:</p> <p>As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:</p>
<dl> <dl>
<di>
<dt>Transmit no data.</dt> <dt>Transmit no data.</dt>
<dd>Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.</dd> <dd>Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.</dd>
</di>
<di>
<dt>If you must transmit, then transmit only a small volume.</dt> <dt>If you must transmit, then transmit only a small volume.</dt>
<dd>If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.</dd> <dd>If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.</dd>
</di>
<di>
<dt>If you must transmit, then compress as hard as possible.</dt> <dt>If you must transmit, then compress as hard as possible.</dt>
<dd>Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.</dd> <dd>Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.</dd>
</di>
<di>
<dt>If you have transmit a lot, then do a lot</dt> <dt>If you have transmit a lot, then do a lot</dt>
<dd>If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.</dd> <dd>If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.</dd>
</di>
<di>
<dt>If you receive, then transmit</dt> <dt>If you receive, then transmit</dt>
<dd>If your peer raises the radio state, you may as well use it.</dd> <dd>If your peer raises the radio state, you may as well use it.</dd>
</di>
</dl> </dl>
<p>And for servers, similar rules apply:</p> <p>And for servers, similar rules apply:</p>
<dl> <dl>
<di>
<dt>Send no data.</dt> <dt>Send no data.</dt>
<dd>Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.</dd> <dd>Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.</dd>
</di>
<di>
<dt>If you must send, send tiny bits.</dt> <dt>If you must send, send tiny bits.</dt>
<dd>Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.</dd> <dd>Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.</dd>
</di>
<di>
<dt>If you receive, then send anything you have.</dt> <dt>If you receive, then send anything you have.</dt>
<dd>Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.</dd> <dd>Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.</dd>
</di>
<di>
<dt>If you must send when not receiving, send plenty.</dt> <dt>If you must send when not receiving, send plenty.</dt>
<dd>Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.</dd> <dd>Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.</dd>
</di>
</dl> </dl>
<p>Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.</p> <p>Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.</p>
</section1> </section1>