Hi!
> Cryogenic is the result of my Master's Thesis, completed at the Technical University
> of Munich under the supervision of Christian Grothoff. You can find more information
> about Cryogenic at https://gnunet.org/cryogenic
Do you have any measurements how much power it actually saves?
What would be cool for phones....
"I'd like to download my mails from IMAP server in next 30
minutes. But... it would be better done when I'm on 3G network with
good signal (0.01W transmit power used for 3 seconds) than on GPRS
with poor signal (2W transmit power for 4 minutes)..."
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 04/11/2014 12:19 PM, Pavel Machek wrote:
> Hi!
>
>> Cryogenic is the result of my Master's Thesis, completed at the Technical University
>> of Munich under the supervision of Christian Grothoff. You can find more information
>> about Cryogenic at https://gnunet.org/cryogenic
>
> Do you have any measurements how much power it actually saves?
Yes, it depends on the device, but we have demonstrated power
savings for two different types of devices using two different
measurement setups performed by two independent groups. Some
of the measurements are available on the website, the second
set should become available "soon" (but we can already say that
for the scenario we measured, the savings are in the same range
as before).
> What would be cool for phones....
Yes, that's largely the point.
> "I'd like to download my mails from IMAP server in next 30
> minutes. But... it would be better done when I'm on 3G network with
> good signal (0.01W transmit power used for 3 seconds) than on GPRS
> with poor signal (2W transmit power for 4 minutes)..."
Well, that's not quite what the API would allow, especially as it
is obviously hard to predict that a different network will become
available.
Hi!
> >> Cryogenic is the result of my Master's Thesis, completed at the Technical University
> >> of Munich under the supervision of Christian Grothoff. You can find more information
> >> about Cryogenic at https://gnunet.org/cryogenic
> >
> > Do you have any measurements how much power it actually saves?
>
> Yes, it depends on the device, but we have demonstrated power
> savings for two different types of devices using two different
> measurement setups performed by two independent groups. Some
> of the measurements are available on the website, the second
> set should become available "soon" (but we can already say that
> for the scenario we measured, the savings are in the same range
> as before).
The video I seen.... AFAICT the savings are in <10% range?
> > "I'd like to download my mails from IMAP server in next 30
> > minutes. But... it would be better done when I'm on 3G network with
> > good signal (0.01W transmit power used for 3 seconds) than on GPRS
> > with poor signal (2W transmit power for 4 minutes)..."
>
> Well, that's not quite what the API would allow, especially as it
> is obviously hard to predict that a different network will become
> available.
Actually... its a phone so it probably has GPS :-). But I'd guess that
even simpler logic, "if UMTS was available in last hour, it is likely
to be available within hour" would work ok.
I seen demo on UDP packets... delayed TCP socket write is probably
easy, but would API allow delayed TCP connect?
Hmm, but the API needs redoing, anyway, fcntl()?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 04/12/2014 12:05 AM, Pavel Machek wrote:
> Hi!
>
>>>> Cryogenic is the result of my Master's Thesis, completed at the Technical University
>>>> of Munich under the supervision of Christian Grothoff. You can find more information
>>>> about Cryogenic at https://gnunet.org/cryogenic
>>>
>>> Do you have any measurements how much power it actually saves?
>>
>> Yes, it depends on the device, but we have demonstrated power
>> savings for two different types of devices using two different
>> measurement setups performed by two independent groups. Some
>> of the measurements are available on the website, the second
>> set should become available "soon" (but we can already say that
>> for the scenario we measured, the savings are in the same range
>> as before).
>
> The video I seen.... AFAICT the savings are in <10% range?
For the scenario we scripted, yes. But note that we only
allowed 50% of the packets transmitted to be delayed (a bit).
If you were to increase the allowed delay or allowed a larger
fraction of packets to be delayed, you should see larger savings.
> I seen demo on UDP packets... delayed TCP socket write is probably
> easy, but would API allow delayed TCP connect?
Yes.
> Hmm, but the API needs redoing, anyway, fcntl()?
Depends --- while I like the idea, I did not hear enough to be
certain that having this feature embedded in such a non-modular
way was already the consensus (and I do not see a reasonable
way to change the API this way while maintaining the modularity
of the current code).
On Sat, 12 Apr 2014, Christian Grothoff wrote:
> On 04/12/2014 12:05 AM, Pavel Machek wrote:
>> Hi!
>>
>>>>> Cryogenic is the result of my Master's Thesis, completed at the Technical University
>>>>> of Munich under the supervision of Christian Grothoff. You can find more information
>>>>> about Cryogenic at https://gnunet.org/cryogenic
>
>> Hmm, but the API needs redoing, anyway, fcntl()?
>
> Depends --- while I like the idea, I did not hear enough to be
> certain that having this feature embedded in such a non-modular
> way was already the consensus (and I do not see a reasonable
> way to change the API this way while maintaining the modularity
> of the current code).
hpa has a good track record for things like this, and there is very little
desire in Linux for things to be kept as an optional add-on module (and cgroups
is a very pointed example of what happens if a capability that people wants gets
ignored).
this sort of capability is something that is very desirable, there are many
people making attempts to provide this sort of event consolidation. So I think
it's _very_ safe to say that if this is accepted, it will be a change to the
core, not just a loadable module.
This means that you need to go through the work hpa was pointing you at, and you
will also need to do some analysis of what the cost is to have this capability
in place, but without the application making use of it (because anything
remotely useful _will_ get enabled in a distro kernel, so how badly does it hurt
high-performance server apps if it's compiled in)
David Lang
Hi!
> >> Yes, it depends on the device, but we have demonstrated power
> >> savings for two different types of devices using two different
> >> measurement setups performed by two independent groups. Some
> >> of the measurements are available on the website, the second
> >> set should become available "soon" (but we can already say that
> >> for the scenario we measured, the savings are in the same range
> >> as before).
> >
> > The video I seen.... AFAICT the savings are in <10% range?
>
> For the scenario we scripted, yes. But note that we only
> allowed 50% of the packets transmitted to be delayed (a bit).
> If you were to increase the allowed delay or allowed a larger
> fraction of packets to be delayed, you should see larger savings.
>
> > I seen demo on UDP packets... delayed TCP socket write is probably
> > easy, but would API allow delayed TCP connect?
>
> Yes.
>
> > Hmm, but the API needs redoing, anyway, fcntl()?
>
> Depends --- while I like the idea, I did not hear enough to be
> certain that having this feature embedded in such a non-modular
> way was already the consensus (and I do not see a reasonable
> way to change the API this way while maintaining the modularity
> of the current code).
Being modular is not important for small piece of code like
this. Having reasonable interface is...
Pavel
On 04/12/2014 04:36 AM, Pavel Machek wrote:
>>
>>> Hmm, but the API needs redoing, anyway, fcntl()?
>>
>> Depends --- while I like the idea, I did not hear enough to be
>> certain that having this feature embedded in such a non-modular
>> way was already the consensus (and I do not see a reasonable
>> way to change the API this way while maintaining the modularity
>> of the current code).
>
> Being modular is not important for small piece of code like
> this. Having reasonable interface is...
>
Yes, it is critical.
-hpa