Elaboración de Modelos Financieros con Excel - Análisis e Interpretación
Panama 22 de Agosto, 2012
SHERATON PANAMA HOTEL & CONVENTION CENTER
Se demostrará paso a paso técnicas financieras con las herramientas o
características de Excel. Aprenderá a utilizar Excel con el propósito de
desarrollar sus
Hi, I found some problem, after upgrade to v5 patch
Host: debian-amd64
Guest: openbsd-amd64
When I cp /mountpoint1/100MB-file to /mountpoint2/, the system hang(no ddb,
no response) , and the host cpu running 100%,
then I need to kill the kvm process on host.
When I scp openbsd-vmguest:/100MB-f
On Wed, Aug 15, 2012 at 06:09:34AM +0100, Jason McIntyre wrote:
> On Tue, Aug 14, 2012 at 10:38:21PM -0400, Lawrence Teo wrote:
> > This is a small follow-up diff to haesbaert@'s recent commit that
> > enables HTTP Basic authentication in ftp(1):
> >
> > * In the AUTO-FETCHING FILES section of the
Now with Philip's fix applied.
* Philip Guenther [120815 15:40]:
> On Sun, Aug 12, 2012 at 12:43 PM, Alexander Polakov wrote:
> > Ok, second attempt
>
> Nice. One fix;
>
>
> > @@ -342,7 +346,10 @@
> > PUSH_STATE(STBRACE);
> >
Achetez vos fleurs, plantes et accessoires directement
Didier Dorin, le conseiller fleuriste, vous conseille sur la qualité et
la quantité
Didier Dorin, le conseiller fleursite, les transforme en décorations
Didier Dorin, le conseiller fleursite, le
On Tue, Aug 14, 2012 at 08:31:31PM +0200, Tobias Ulmer wrote:
> Finally got around to dig out the card and put it in a Blade 1500. With
> -current, I get around 10Mb using tcpbench. With your diff,
> freelist corruption messages pop up rather quickly, speed is the same. I
> guess the panic at the e
On Aug 15, 2012, at 8:17 PM, Ted Unangst wrote:
> On Wed, Aug 15, 2012 at 13:25, Ted Unangst wrote:
>
> I will probably rename this just "tsc" after some prodding from mikeb,
> that's a better name. I tend to focus on the instruction used, but we
> should name it after the counter.
>
>> +r
On Wed, Aug 15, 2012 at 13:25, Ted Unangst wrote:
I will probably rename this just "tsc" after some prodding from mikeb,
that's a better name. I tend to focus on the instruction used, but we
should name it after the counter.
> + rdtsc_timecounter.tc_frequency = cpuspeed;
> + /* cpuspeed
So for more than a decade, the rdtsc instruction has in theory been
the fastest most accurate way to measure elapsed time on x86. Except
when it doesn't quite work.
The main issues are 1) frequency changing as a result of power
management, and 2) different values on different CPUs in SMP systems.
> Date: Wed, 15 Aug 2012 11:58:28 -0400
> From: Ted Unangst
>
> On Wed, Aug 15, 2012 at 17:36, Mike Belopuhov wrote:
> > On Wed, Aug 15, 2012 at 5:02 PM, Ted Unangst wrote:
> >> The acpihpet timer is, in my testing, lots better than the acpitimer.
> >> Faster to read and more precise. They shou
On Wed, Aug 15, 2012 at 17:36, Mike Belopuhov wrote:
> On Wed, Aug 15, 2012 at 5:02 PM, Ted Unangst wrote:
>> The acpihpet timer is, in my testing, lots better than the acpitimer.
>> Faster to read and more precise. They should not have the same quality
>> value. Double acpihpet.
>>
>
> as long
On Wed, Aug 15, 2012 at 5:36 PM, Mike Belopuhov wrote:
> On Wed, Aug 15, 2012 at 5:02 PM, Ted Unangst wrote:
>> The acpihpet timer is, in my testing, lots better than the acpitimer.
>> Faster to read and more precise. They should not have the same quality
>> value. Double acpihpet.
>>
>
> as lo
On Wed, Aug 15, 2012 at 17:21, Mark Kettenis wrote:
>> Date: Wed, 15 Aug 2012 11:02:43 -0400
>> From: Ted Unangst
>>
>> The acpihpet timer is, in my testing, lots better than the acpitimer.
>> Faster to read and more precise. They should not have the same quality
>> value. Double acpihpet.
>
>
On Wed, Aug 15, 2012 at 5:02 PM, Ted Unangst wrote:
> The acpihpet timer is, in my testing, lots better than the acpitimer.
> Faster to read and more precise. They should not have the same quality
> value. Double acpihpet.
>
as long as acpi subsystem attaches acpitimer earlier we don't
need tha
This reminds me...
On Wed, Aug 15, 2012 at 8:02 AM, Ted Unangst wrote:
> 0x, /* counter_mask (24 bits) */
... this comment has been bugging me for a while. I'm pretty sure it
should be "32 bits". Seems like a bad copy/paste from acpitimer.c.
> Date: Wed, 15 Aug 2012 11:02:43 -0400
> From: Ted Unangst
>
> The acpihpet timer is, in my testing, lots better than the acpitimer.
> Faster to read and more precise. They should not have the same quality
> value. Double acpihpet.
Since both acpitimer(4) and acpihpet(4) are based on an abstr
timecounters are here to stay, at least for those archs where
timecounters have arrived. remove some now useless guards.
Index: arch/i386/pci/geodesc.c
===
RCS file: /cvs/src/sys/arch/i386/pci/geodesc.c,v
retrieving revision 1.9
diff
The acpihpet timer is, in my testing, lots better than the acpitimer.
Faster to read and more precise. They should not have the same quality
value. Double acpihpet.
Index: acpihpet.c
===
RCS file: /cvs/src/sys/dev/acpi/acpihpet.c,v
On Wed, Aug 15, 2012 at 04:46:46PM +0200, Mark Kettenis wrote:
> > Date: Wed, 15 Aug 2012 16:31:53 +0200
> > From: Antoine Jacoutot
> >
> > On Sun, Aug 12, 2012 at 01:22:55PM +1000, David Gwynne wrote:
> > > ive been beating my head against why mpi is slow on some machines
> > > and not others, a
> Date: Wed, 15 Aug 2012 16:31:53 +0200
> From: Antoine Jacoutot
>
> On Sun, Aug 12, 2012 at 01:22:55PM +1000, David Gwynne wrote:
> > ive been beating my head against why mpi is slow on some machines
> > and not others, and i think this may be why.
> >
> > issuing a command to the chip is done
On Sun, Aug 12, 2012 at 01:22:55PM +1000, David Gwynne wrote:
> ive been beating my head against why mpi is slow on some machines
> and not others, and i think this may be why.
>
> issuing a command to the chip is done by posting its address to a
> register. in my code this was done by doing a wri
On 08/15/2012 09:07 AM, Henning Brauer wrote:
> * Simon Perreault [2012-08-15 14:38]:
>> Le 2012-08-14 20:29, David Gwynne a écrit :
>>> ill have to fix that.
>> Oh, and I also realized that CBQ is even worse: it calls
>> microuptime() on every enqueue *and* every dequeue!
>>
>> If it really was a
* Simon Perreault [2012-08-15 14:38]:
> Le 2012-08-14 20:29, David Gwynne a écrit :
> >ill have to fix that.
>
> Oh, and I also realized that CBQ is even worse: it calls
> microuptime() on every enqueue *and* every dequeue!
>
> If it really was a bug, people would have noticed, no?
altq being s
Le 2012-08-14 20:29, David Gwynne a écrit :
ill have to fix that.
Oh, and I also realized that CBQ is even worse: it calls microuptime()
on every enqueue *and* every dequeue!
If it really was a bug, people would have noticed, no?
Simon
On 15/08/2012, at 3:31 AM, Simon Perreault wrote:
Actually there is two different functions for freeing usb devices
resources:
- usbd_remove_device() which is only called if an error occurs when
adding a new device
- usb_free_device() which is called when a device is detached
The diff below merge the two functions into one and as a side e
25 matches
Mail list logo
