Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1560009 > unrolled thread
| Started by | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| First post | 2017-01-16 20:40 +0100 |
| Last post | 2017-01-18 17:10 +0100 |
| Articles | 20 on this page of 25 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-16 20:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-16 20:50 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-16 21:10 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Miroslav Lichvar <mlichvar@redhat.com> - 2017-01-17 09:10 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-17 12:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Radim Krcmar <rkrcmar@redhat.com> - 2017-01-17 16:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-18 13:20 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-18 13:30 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Paolo Bonzini <pbonzini@redhat.com> - 2017-01-18 13:50 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Miroslav Lichvar <mlichvar@redhat.com> - 2017-01-18 14:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Paolo Bonzini <pbonzini@redhat.com> - 2017-01-18 15:20 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-18 16:00 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Radim Krcmar <rkrcmar@redhat.com> - 2017-01-18 16:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Paolo Bonzini <pbonzini@redhat.com> - 2017-01-18 17:00 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-20 11:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-18 15:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Miroslav Lichvar <mlichvar@redhat.com> - 2017-01-18 17:00 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Paolo Bonzini <pbonzini@redhat.com> - 2017-01-18 17:10 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Radim Krcmar <rkrcmar@redhat.com> - 2017-01-18 17:20 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-18 15:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-18 16:00 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Radim Krcmar <rkrcmar@redhat.com> - 2017-01-18 16:30 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Marcelo Tosatti <mtosatti@redhat.com> - 2017-01-20 11:40 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Radim Krcmar <rkrcmar@redhat.com> - 2017-01-20 15:30 +0100
Re: [patch 3/3] PTP: add kvm PTP driver Radim Krcmar <rkrcmar@redhat.com> - 2017-01-18 17:10 +0100
Page 1 of 2 [1] 2 Next page →
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-16 20:40 +0100 |
| Subject | Re: [patch 3/3] PTP: add kvm PTP driver |
| Message-ID | <t0lih-54V-7@gated-at.bofh.it> |
On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote: > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ > > of the host clock. > > That is pretty good. Yes. > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() - > > guest_tsc) part ? > > Yes, it results in simpler code, doesn't create dependency on the > dreaded kvmclock, and is the best we can currently do wrt. precision. Sorry, unless i am misunderstanding how this works, it'll get the guest clock 2us behind, which is something not wanted. Miroslav, if ->gettime64 returns the host realtime at 2us in the past, this means Chrony will sync the guest clock to host realtime - 2us Is that correct?
[toc] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-16 20:50 +0100 |
| Message-ID | <t0lrX-58K-17@gated-at.bofh.it> |
| In reply to | #1560009 |
On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote: > On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote: > > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ > > > of the host clock. > > > > That is pretty good. > > Yes. > > > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() - > > > guest_tsc) part ? > > > > Yes, it results in simpler code, doesn't create dependency on the > > dreaded kvmclock, and is the best we can currently do wrt. precision. Even if the PHC sync algorithm manages to detect that the clock read is incorrect, consider the following: Variability in the VM-entry code path, such as cache effects and interrupts would cause certain readings to be longer then the average (assuming an average where cache is hot). Using the TSC removes this variability, which can be large in case of non realtime guests, where you do: 1. kvm_hypercall. 2. read host realtime clock. 3. schedule out qemu-kvm vcpu. 4. schedule in qemu-kvm vcpu. So using the delta between read host realtime and ->gettime64 increases precision and decreases variability. > Sorry, unless i am misunderstanding how this works, it'll get the guest clock > 2us behind, which is something not wanted. > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, > this means Chrony will sync the guest clock to > > host realtime - 2us > > Is that correct? >
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-16 21:10 +0100 |
| Message-ID | <t0lLk-5zl-19@gated-at.bofh.it> |
| In reply to | #1560022 |
On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote: > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote: > > On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote: > > > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ > > > > of the host clock. > > > > > > That is pretty good. > > > > Yes. > > > > > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() - > > > > guest_tsc) part ? > > > > > > Yes, it results in simpler code, doesn't create dependency on the > > > dreaded kvmclock, and is the best we can currently do wrt. precision. > > Even if the PHC sync algorithm manages to detect that the clock read is > incorrect, consider the following: > > Variability in the VM-entry code path, such as cache effects and interrupts would cause > certain readings to be longer then the average (assuming an average > where cache is hot). > > Using the TSC removes this variability, which can be large in case of > non realtime guests, where you do: > > 1. kvm_hypercall. > 2. read host realtime clock. > 3. schedule out qemu-kvm vcpu. > 4. schedule in qemu-kvm vcpu. > > So using the delta between read host realtime and > ->gettime64 increases precision and decreases variability. > > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock > > 2us behind, which is something not wanted. > > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, > > this means Chrony will sync the guest clock to > > > > host realtime - 2us > > > > Is that correct? Drop the offset correction and the following happens: Clock offset seems to vary between negative hundreds of ns: 210 Number of sources = 1 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 0 3 377 11 -131ns[ -309ns] +/- 3ns And positive: 210 Number of sources = 1 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 0 3 377 4 +79ns[ +155ns] +/- 3ns
[toc] | [prev] | [next] | [standalone]
| From | Miroslav Lichvar <mlichvar@redhat.com> |
|---|---|
| Date | 2017-01-17 09:10 +0100 |
| Message-ID | <t0x06-4x1-13@gated-at.bofh.it> |
| In reply to | #1560027 |
On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote:
> On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote:
> > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote:
> > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock
> > > 2us behind, which is something not wanted.
> > >
> > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past,
> > > this means Chrony will sync the guest clock to
> > >
> > > host realtime - 2us
> > >
> > > Is that correct?
Probably. It depends on the error of both host and guest timestamps.
If the error is the same on both sides, it will cancel out. An
occasional spike in the delay shouldn't be a problem as the reading
will be filtered out, but for best accuracy it's necessary that the
host's timestamp is taken in the middle between the guest's
timestamps.
Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2
corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on.
ts[1] ts[3]
Host time ---------+---------+........
| |
| |
Guest time ----+---------+---------+......
ts[0] ts[2] ts[4]
--
Miroslav Lichvar
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-17 12:40 +0100 |
| Message-ID | <t0Ahj-6wt-15@gated-at.bofh.it> |
| In reply to | #1560320 |
On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote: > On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote: > > On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote: > > > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote: > > > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock > > > > 2us behind, which is something not wanted. > > > > > > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, > > > > this means Chrony will sync the guest clock to > > > > > > > > host realtime - 2us > > > > > > > > Is that correct? > > Probably. It depends on the error of both host and guest timestamps. > If the error is the same on both sides, it will cancel out. An > occasional spike in the delay shouldn't be a problem as the reading > will be filtered out, but for best accuracy it's necessary that the > host's timestamp is taken in the middle between the guest's > timestamps. The problem is that spikes can be far from occasional: it depends on activity of the host CPU and interrupts. Whose delay can be "intermittent": as long as interrupts are being sent to the host CPU, for example, the delay will be high (which can last minutes). The TSC reading in the guest KVM PTP driver corrects for that delay. > Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2 > corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on. > > ts[1] ts[3] > Host time ---------+---------+........ > | | > | | > Guest time ----+---------+---------+...... > ts[0] ts[2] ts[4] > > -- > Miroslav Lichvar
[toc] | [prev] | [next] | [standalone]
| From | Radim Krcmar <rkrcmar@redhat.com> |
|---|---|
| Date | 2017-01-17 16:40 +0100 |
| Message-ID | <t0E1A-mt-29@gated-at.bofh.it> |
| In reply to | #1560519 |
2017-01-17 09:30-0200, Marcelo Tosatti:
> On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote:
>> On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote:
>> > On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote:
>> > > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote:
>> > > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock
>> > > > 2us behind, which is something not wanted.
>> > > >
>> > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past,
>> > > > this means Chrony will sync the guest clock to
>> > > >
>> > > > host realtime - 2us
>> > > >
>> > > > Is that correct?
>>
>> Probably. It depends on the error of both host and guest timestamps.
>> If the error is the same on both sides, it will cancel out. An
>> occasional spike in the delay shouldn't be a problem as the reading
>> will be filtered out, but for best accuracy it's necessary that the
>> host's timestamp is taken in the middle between the guest's
>> timestamps.
>
> The problem is that spikes can be far from occasional: it depends on activity of
> the host CPU and interrupts. Whose delay can be "intermittent": as long
> as interrupts are being sent to the host CPU, for example, the delay
> will be high (which can last minutes).
>
> The TSC reading in the guest KVM PTP driver corrects for that delay.
>
>> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2
>> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on.
>>
>> ts[1] ts[3]
>> Host time ---------+---------+........
>> | |
>> | |
>> Guest time ----+---------+---------+......
>> ts[0] ts[2] ts[4]
KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes
the offset very consistent, so the graph would look like:
ts[1] ts[3]
Host time -------------+---------+........
| |
| |
Guest time ----+---------+---------+......
ts[0] ts[2] ts[4]
which doesn't sound good if users assume that the host reading is in the
middle -- the guest time would be ahead of the host time.
I'm wondering why is the PTP precision around 10ns, when the hypercall
takes around 2-3k cycles. Have you measured the guest<->host offset by
getting the output of the hypercall, i.e.
{host_sec @ tsc, host_nsec @ tsc, tsc}
and comparing it with guest time computed from the same tsc, i.e.
{guest_sec @ tsc, guest_nsec @ tsc}
?
Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-18 13:20 +0100 |
| Message-ID | <t0XnA-3ZK-19@gated-at.bofh.it> |
| In reply to | #1560723 |
On Tue, Jan 17, 2017 at 04:36:21PM +0100, Radim Krcmar wrote:
> 2017-01-17 09:30-0200, Marcelo Tosatti:
> > On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote:
> >> On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote:
> >> > On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote:
> >> > > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote:
> >> > > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock
> >> > > > 2us behind, which is something not wanted.
> >> > > >
> >> > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past,
> >> > > > this means Chrony will sync the guest clock to
> >> > > >
> >> > > > host realtime - 2us
> >> > > >
> >> > > > Is that correct?
> >>
> >> Probably. It depends on the error of both host and guest timestamps.
> >> If the error is the same on both sides, it will cancel out. An
> >> occasional spike in the delay shouldn't be a problem as the reading
> >> will be filtered out, but for best accuracy it's necessary that the
> >> host's timestamp is taken in the middle between the guest's
> >> timestamps.
> >
> > The problem is that spikes can be far from occasional: it depends on activity of
> > the host CPU and interrupts. Whose delay can be "intermittent": as long
> > as interrupts are being sent to the host CPU, for example, the delay
> > will be high (which can last minutes).
> >
> > The TSC reading in the guest KVM PTP driver corrects for that delay.
> >
> >> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2
> >> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on.
> >>
> >> ts[1] ts[3]
> >> Host time ---------+---------+........
> >> | |
> >> | |
> >> Guest time ----+---------+---------+......
> >> ts[0] ts[2] ts[4]
>
> KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes
> the offset very consistent, so the graph would look like:
>
> ts[1] ts[3]
> Host time -------------+---------+........
> | |
> | |
> Guest time ----+---------+---------+......
> ts[0] ts[2] ts[4]
>
> which doesn't sound good if users assume that the host reading is in the
> middle -- the guest time would be ahead of the host time.
>
> I'm wondering why is the PTP precision around 10ns, when the hypercall
> takes around 2-3k cycles. Have you measured the guest<->host offset by
> getting the output of the hypercall, i.e.
> {host_sec @ tsc, host_nsec @ tsc, tsc}
> and comparing it with guest time computed from the same tsc, i.e.
> {guest_sec @ tsc, guest_nsec @ tsc}
> ?
>
> Thanks.
Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating
intense interrupts). Follows results:
Without TSC delta calculation:
=============================
#* PHC0 0 3 377 2 -99ns[ +206ns] +/- 116ns
#* PHC0 0 3 377 8 +202ns[ +249ns] +/- 111ns
#* PHC0 0 3 377 8 -213ns[ +683ns] +/- 88ns
#* PHC0 0 3 377 6 +77ns[ +319ns] +/- 56ns
#* PHC0 0 3 377 4 -771ns[-1029ns] +/- 93ns
#* PHC0 0 3 377 10 -49ns[ -58ns] +/- 121ns
#* PHC0 0 3 377 9 +562ns[ +703ns] +/- 107ns
#* PHC0 0 3 377 6 -2ns[ -3ns] +/- 94ns
#* PHC0 0 3 377 4 +451ns[ +494ns] +/- 138ns
#* PHC0 0 3 377 11 -67ns[ -74ns] +/- 113ns
#* PHC0 0 3 377 8 +244ns[ +264ns] +/- 119ns
#* PHC0 0 3 377 7 -696ns[ -890ns] +/- 89ns
#* PHC0 0 3 377 4 +468ns[ +560ns] +/- 110ns
#* PHC0 0 3 377 11 -310ns[ -430ns] +/- 72ns
#* PHC0 0 3 377 9 +189ns[ +298ns] +/- 54ns
#* PHC0 0 3 377 7 +594ns[ +473ns] +/- 96ns
#* PHC0 0 3 377 5 +151ns[ +280ns] +/- 71ns
#* PHC0 0 3 377 10 -590ns[ -696ns] +/- 94ns
#* PHC0 0 3 377 8 +415ns[ +526ns] +/- 74ns
#* PHC0 0 3 377 6 +1381ns[+1469ns] +/- 101ns
#* PHC0 0 3 377 4 +571ns[+1304ns] +/- 54ns
#* PHC0 0 3 377 8 -5ns[ +71ns] +/- 139ns
#* PHC0 0 3 377 7 -247ns[ -502ns] +/- 69ns
#* PHC0 0 3 377 5 -283ns[ +879ns] +/- 73ns
#* PHC0 0 3 377 3 +148ns[ -109ns] +/- 61ns
With TSC delta calculation:
============================
#* PHC0 0 3 377 7 +379ns[ +432ns] +/- 53ns
#* PHC0 0 3 377 9 +106ns[ +420ns] +/- 42ns
#* PHC0 0 3 377 7 -58ns[ -136ns] +/- 62ns
#* PHC0 0 3 377 12 +93ns[ -38ns] +/- 64ns
#* PHC0 0 3 377 8 +84ns[ +107ns] +/- 69ns
#* PHC0 0 3 377 3 -76ns[ -103ns] +/- 52ns
#* PHC0 0 3 377 7 +52ns[ +63ns] +/- 50ns
#* PHC0 0 3 377 11 +29ns[ +31ns] +/- 70ns
#* PHC0 0 3 377 7 -47ns[ -56ns] +/- 42ns
#* PHC0 0 3 377 10 -35ns[ -42ns] +/- 33ns
#* PHC0 0 3 377 7 -32ns[ -34ns] +/- 42ns
#* PHC0 0 3 377 11 -172ns[ -173ns] +/- 118ns
#* PHC0 0 3 377 6 +65ns[ +76ns] +/- 23ns
#* PHC0 0 3 377 9 +18ns[ +23ns] +/- 37ns
#* PHC0 0 3 377 6 +41ns[ -60ns] +/- 30ns
#* PHC0 0 3 377 10 +39ns[ +183ns] +/- 42ns
#* PHC0 0 3 377 6 +50ns[ +102ns] +/- 86ns
#* PHC0 0 3 377 11 +50ns[ +75ns] +/- 52ns
#* PHC0 0 3 377 6 +50ns[ +116ns] +/- 100ns
#* PHC0 0 3 377 10 +46ns[ +65ns] +/- 79ns
#* PHC0 0 3 377 7 -38ns[ -51ns] +/- 29ns
#* PHC0 0 3 377 10 -11ns[ -12ns] +/- 32ns
#* PHC0 0 3 377 7 -31ns[ -32ns] +/- 99ns
#* PHC0 0 3 377 10 +222ns[ +238ns] +/- 58ns
#* PHC0 0 3 377 6 +185ns[ +207ns] +/- 39ns
#* PHC0 0 3 377 10 -392ns[ -394ns] +/- 118ns
#* PHC0 0 3 377 6 -9ns[ -50ns] +/- 35ns
#* PHC0 0 3 377 10 -346ns[ -355ns] +/- 111ns
Do you still want to drop it in favour of simplicity?
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-18 13:30 +0100 |
| Message-ID | <t0Xxh-430-37@gated-at.bofh.it> |
| In reply to | #1561694 |
On Wed, Jan 18, 2017 at 10:17:38AM -0200, Marcelo Tosatti wrote:
> On Tue, Jan 17, 2017 at 04:36:21PM +0100, Radim Krcmar wrote:
> > 2017-01-17 09:30-0200, Marcelo Tosatti:
> > > On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote:
> > >> On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote:
> > >> > On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote:
> > >> > > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote:
> > >> > > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock
> > >> > > > 2us behind, which is something not wanted.
> > >> > > >
> > >> > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past,
> > >> > > > this means Chrony will sync the guest clock to
> > >> > > >
> > >> > > > host realtime - 2us
> > >> > > >
> > >> > > > Is that correct?
> > >>
> > >> Probably. It depends on the error of both host and guest timestamps.
> > >> If the error is the same on both sides, it will cancel out. An
> > >> occasional spike in the delay shouldn't be a problem as the reading
> > >> will be filtered out, but for best accuracy it's necessary that the
> > >> host's timestamp is taken in the middle between the guest's
> > >> timestamps.
> > >
> > > The problem is that spikes can be far from occasional: it depends on activity of
> > > the host CPU and interrupts. Whose delay can be "intermittent": as long
> > > as interrupts are being sent to the host CPU, for example, the delay
> > > will be high (which can last minutes).
> > >
> > > The TSC reading in the guest KVM PTP driver corrects for that delay.
> > >
> > >> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2
> > >> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on.
> > >>
> > >> ts[1] ts[3]
> > >> Host time ---------+---------+........
> > >> | |
> > >> | |
> > >> Guest time ----+---------+---------+......
> > >> ts[0] ts[2] ts[4]
> >
> > KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes
> > the offset very consistent, so the graph would look like:
> >
> > ts[1] ts[3]
> > Host time -------------+---------+........
> > | |
> > | |
> > Guest time ----+---------+---------+......
> > ts[0] ts[2] ts[4]
> >
> > which doesn't sound good if users assume that the host reading is in the
> > middle -- the guest time would be ahead of the host time.
> >
> > I'm wondering why is the PTP precision around 10ns, when the hypercall
> > takes around 2-3k cycles. Have you measured the guest<->host offset by
> > getting the output of the hypercall, i.e.
> > {host_sec @ tsc, host_nsec @ tsc, tsc}
> > and comparing it with guest time computed from the same tsc, i.e.
> > {guest_sec @ tsc, guest_nsec @ tsc}
> > ?
> >
> > Thanks.
>
> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating
> intense interrupts). Follows results:
>
> Without TSC delta calculation:
> =============================
>
> #* PHC0 0 3 377 2 -99ns[ +206ns] +/- 116ns
> #* PHC0 0 3 377 8 +202ns[ +249ns] +/- 111ns
> #* PHC0 0 3 377 8 -213ns[ +683ns] +/- 88ns
> #* PHC0 0 3 377 6 +77ns[ +319ns] +/- 56ns
> #* PHC0 0 3 377 4 -771ns[-1029ns] +/- 93ns
> #* PHC0 0 3 377 10 -49ns[ -58ns] +/- 121ns
> #* PHC0 0 3 377 9 +562ns[ +703ns] +/- 107ns
> #* PHC0 0 3 377 6 -2ns[ -3ns] +/- 94ns
> #* PHC0 0 3 377 4 +451ns[ +494ns] +/- 138ns
> #* PHC0 0 3 377 11 -67ns[ -74ns] +/- 113ns
> #* PHC0 0 3 377 8 +244ns[ +264ns] +/- 119ns
> #* PHC0 0 3 377 7 -696ns[ -890ns] +/- 89ns
> #* PHC0 0 3 377 4 +468ns[ +560ns] +/- 110ns
> #* PHC0 0 3 377 11 -310ns[ -430ns] +/- 72ns
> #* PHC0 0 3 377 9 +189ns[ +298ns] +/- 54ns
> #* PHC0 0 3 377 7 +594ns[ +473ns] +/- 96ns
> #* PHC0 0 3 377 5 +151ns[ +280ns] +/- 71ns
> #* PHC0 0 3 377 10 -590ns[ -696ns] +/- 94ns
> #* PHC0 0 3 377 8 +415ns[ +526ns] +/- 74ns
> #* PHC0 0 3 377 6 +1381ns[+1469ns] +/- 101ns
> #* PHC0 0 3 377 4 +571ns[+1304ns] +/- 54ns
> #* PHC0 0 3 377 8 -5ns[ +71ns] +/- 139ns
> #* PHC0 0 3 377 7 -247ns[ -502ns] +/- 69ns
> #* PHC0 0 3 377 5 -283ns[ +879ns] +/- 73ns
> #* PHC0 0 3 377 3 +148ns[ -109ns] +/- 61ns
>
> With TSC delta calculation:
> ============================
>
> #* PHC0 0 3 377 7 +379ns[ +432ns] +/- 53ns
> #* PHC0 0 3 377 9 +106ns[ +420ns] +/- 42ns
> #* PHC0 0 3 377 7 -58ns[ -136ns] +/- 62ns
> #* PHC0 0 3 377 12 +93ns[ -38ns] +/- 64ns
> #* PHC0 0 3 377 8 +84ns[ +107ns] +/- 69ns
> #* PHC0 0 3 377 3 -76ns[ -103ns] +/- 52ns
> #* PHC0 0 3 377 7 +52ns[ +63ns] +/- 50ns
> #* PHC0 0 3 377 11 +29ns[ +31ns] +/- 70ns
> #* PHC0 0 3 377 7 -47ns[ -56ns] +/- 42ns
> #* PHC0 0 3 377 10 -35ns[ -42ns] +/- 33ns
> #* PHC0 0 3 377 7 -32ns[ -34ns] +/- 42ns
> #* PHC0 0 3 377 11 -172ns[ -173ns] +/- 118ns
> #* PHC0 0 3 377 6 +65ns[ +76ns] +/- 23ns
> #* PHC0 0 3 377 9 +18ns[ +23ns] +/- 37ns
> #* PHC0 0 3 377 6 +41ns[ -60ns] +/- 30ns
> #* PHC0 0 3 377 10 +39ns[ +183ns] +/- 42ns
> #* PHC0 0 3 377 6 +50ns[ +102ns] +/- 86ns
> #* PHC0 0 3 377 11 +50ns[ +75ns] +/- 52ns
> #* PHC0 0 3 377 6 +50ns[ +116ns] +/- 100ns
> #* PHC0 0 3 377 10 +46ns[ +65ns] +/- 79ns
> #* PHC0 0 3 377 7 -38ns[ -51ns] +/- 29ns
> #* PHC0 0 3 377 10 -11ns[ -12ns] +/- 32ns
> #* PHC0 0 3 377 7 -31ns[ -32ns] +/- 99ns
> #* PHC0 0 3 377 10 +222ns[ +238ns] +/- 58ns
> #* PHC0 0 3 377 6 +185ns[ +207ns] +/- 39ns
> #* PHC0 0 3 377 10 -392ns[ -394ns] +/- 118ns
> #* PHC0 0 3 377 6 -9ns[ -50ns] +/- 35ns
> #* PHC0 0 3 377 10 -346ns[ -355ns] +/- 111ns
>
>
> Do you still want to drop it in favour of simplicity?
>
This is the output of "chronyc sources". See section "Time sources"
of https://chrony.tuxfamily.org/doc/2.4/chronyc.html.
[toc] | [prev] | [next] | [standalone]
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Date | 2017-01-18 13:50 +0100 |
| Message-ID | <t0XQC-49m-7@gated-at.bofh.it> |
| In reply to | #1561707 |
On 18/01/2017 13:24, Marcelo Tosatti wrote: > On Wed, Jan 18, 2017 at 10:17:38AM -0200, Marcelo Tosatti wrote: >> On Tue, Jan 17, 2017 at 04:36:21PM +0100, Radim Krcmar wrote: >>> 2017-01-17 09:30-0200, Marcelo Tosatti: >>>> On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote: >>>>> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2 >>>>> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on. >>>>> >>>>> ts[1] ts[3] >>>>> Host time ---------+---------+........ >>>>> | | >>>>> | | >>>>> Guest time ----+---------+---------+...... >>>>> ts[0] ts[2] ts[4] >>> >>> KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes >>> the offset very consistent, so the graph would look like: >>> >>> ts[1] ts[3] >>> Host time -------------+---------+........ >>> | | >>> | | >>> Guest time ----+---------+---------+...... >>> ts[0] ts[2] ts[4] >>> >>> which doesn't sound good if users assume that the host reading is in the >>> middle -- the guest time would be ahead of the host time. >> >> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating >> intense interrupts). Follows results: >> >> Without TSC delta calculation: >> ============================= >> >> #* PHC0 0 3 377 2 -99ns[ +206ns] +/- 116ns >> #* PHC0 0 3 377 8 +202ns[ +249ns] +/- 111ns >> #* PHC0 0 3 377 8 -213ns[ +683ns] +/- 88ns >> #* PHC0 0 3 377 6 +77ns[ +319ns] +/- 56ns >> #* PHC0 0 3 377 4 -771ns[-1029ns] +/- 93ns >> #* PHC0 0 3 377 10 -49ns[ -58ns] +/- 121ns >> #* PHC0 0 3 377 9 +562ns[ +703ns] +/- 107ns >> #* PHC0 0 3 377 6 -2ns[ -3ns] +/- 94ns >> #* PHC0 0 3 377 4 +451ns[ +494ns] +/- 138ns >> #* PHC0 0 3 377 11 -67ns[ -74ns] +/- 113ns >> #* PHC0 0 3 377 8 +244ns[ +264ns] +/- 119ns >> #* PHC0 0 3 377 7 -696ns[ -890ns] +/- 89ns >> #* PHC0 0 3 377 4 +468ns[ +560ns] +/- 110ns >> #* PHC0 0 3 377 11 -310ns[ -430ns] +/- 72ns >> #* PHC0 0 3 377 9 +189ns[ +298ns] +/- 54ns >> #* PHC0 0 3 377 7 +594ns[ +473ns] +/- 96ns >> #* PHC0 0 3 377 5 +151ns[ +280ns] +/- 71ns >> #* PHC0 0 3 377 10 -590ns[ -696ns] +/- 94ns >> #* PHC0 0 3 377 8 +415ns[ +526ns] +/- 74ns >> #* PHC0 0 3 377 6 +1381ns[+1469ns] +/- 101ns >> #* PHC0 0 3 377 4 +571ns[+1304ns] +/- 54ns >> #* PHC0 0 3 377 8 -5ns[ +71ns] +/- 139ns >> #* PHC0 0 3 377 7 -247ns[ -502ns] +/- 69ns >> #* PHC0 0 3 377 5 -283ns[ +879ns] +/- 73ns >> #* PHC0 0 3 377 3 +148ns[ -109ns] +/- 61ns >> >> With TSC delta calculation: >> ============================ >> >> #* PHC0 0 3 377 7 +379ns[ +432ns] +/- 53ns >> #* PHC0 0 3 377 9 +106ns[ +420ns] +/- 42ns >> #* PHC0 0 3 377 7 -58ns[ -136ns] +/- 62ns >> #* PHC0 0 3 377 12 +93ns[ -38ns] +/- 64ns >> #* PHC0 0 3 377 8 +84ns[ +107ns] +/- 69ns >> #* PHC0 0 3 377 3 -76ns[ -103ns] +/- 52ns >> #* PHC0 0 3 377 7 +52ns[ +63ns] +/- 50ns >> #* PHC0 0 3 377 11 +29ns[ +31ns] +/- 70ns >> #* PHC0 0 3 377 7 -47ns[ -56ns] +/- 42ns >> #* PHC0 0 3 377 10 -35ns[ -42ns] +/- 33ns >> #* PHC0 0 3 377 7 -32ns[ -34ns] +/- 42ns >> #* PHC0 0 3 377 11 -172ns[ -173ns] +/- 118ns >> #* PHC0 0 3 377 6 +65ns[ +76ns] +/- 23ns >> #* PHC0 0 3 377 9 +18ns[ +23ns] +/- 37ns >> #* PHC0 0 3 377 6 +41ns[ -60ns] +/- 30ns >> #* PHC0 0 3 377 10 +39ns[ +183ns] +/- 42ns >> #* PHC0 0 3 377 6 +50ns[ +102ns] +/- 86ns >> #* PHC0 0 3 377 11 +50ns[ +75ns] +/- 52ns >> #* PHC0 0 3 377 6 +50ns[ +116ns] +/- 100ns >> #* PHC0 0 3 377 10 +46ns[ +65ns] +/- 79ns >> #* PHC0 0 3 377 7 -38ns[ -51ns] +/- 29ns >> #* PHC0 0 3 377 10 -11ns[ -12ns] +/- 32ns >> #* PHC0 0 3 377 7 -31ns[ -32ns] +/- 99ns >> #* PHC0 0 3 377 10 +222ns[ +238ns] +/- 58ns >> #* PHC0 0 3 377 6 +185ns[ +207ns] +/- 39ns >> #* PHC0 0 3 377 10 -392ns[ -394ns] +/- 118ns >> #* PHC0 0 3 377 6 -9ns[ -50ns] +/- 35ns >> #* PHC0 0 3 377 10 -346ns[ -355ns] +/- 111ns >> >> >> Do you still want to drop it in favour of simplicity? > > This is the output of "chronyc sources". See section "Time sources" > of https://chrony.tuxfamily.org/doc/2.4/chronyc.html. It's just that it's not obvious why you get better results with biased host timestamps. What makes the biased host timestamp more precise? I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony does not support it---but I would still prefer you to support PTP_SYS_OFFSET_PRECISE as well. Paolo
[toc] | [prev] | [next] | [standalone]
| From | Miroslav Lichvar <mlichvar@redhat.com> |
|---|---|
| Date | 2017-01-18 14:40 +0100 |
| Message-ID | <t0YD1-4Gk-49@gated-at.bofh.it> |
| In reply to | #1561724 |
On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote: > On 18/01/2017 13:24, Marcelo Tosatti wrote: > >> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating > >> intense interrupts). Follows results: > >> Do you still want to drop it in favour of simplicity? > It's just that it's not obvious why you get better results with biased > host timestamps. What makes the biased host timestamp more precise? > > I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony > does not support it---but I would still prefer you to support > PTP_SYS_OFFSET_PRECISE as well. Interesting. I wasn't aware that there is a new ioctl for measuring the HW-sys offset. Adding support to chrony shouldn't be difficult. If I understand it correctly, PTP_SYS_OFFSET can be emulated on top of PTP_SYS_OFFSET_PRECISE simply by copying the sys_realtime and device fields to corresponding ts slots. The apparent delay will be zero, but that's ok if the conversion is really accurate. I'm not sure if trying to do that in the opposite direction is a good idea. An application using PTP_SYS_OFFSET_PRECISE may assume the conversion is accurate and not include any delay/dispersion in an estimate of the maximum error, which is needed in NTP for instance. If we know the host timestamp ts[1] is not in the middle between the guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not simply shift ts[1] by (ts[2]-ts[0])/2 ? -- Miroslav Lichvar
[toc] | [prev] | [next] | [standalone]
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Date | 2017-01-18 15:20 +0100 |
| Message-ID | <t0ZfI-594-13@gated-at.bofh.it> |
| In reply to | #1561810 |
On 18/01/2017 14:36, Miroslav Lichvar wrote:
> On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote:
>> On 18/01/2017 13:24, Marcelo Tosatti wrote:
>>>> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating
>>>> intense interrupts). Follows results:
>
>>>> Do you still want to drop it in favour of simplicity?
>
>> It's just that it's not obvious why you get better results with biased
>> host timestamps. What makes the biased host timestamp more precise?
>>
>> I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony
>> does not support it---but I would still prefer you to support
>> PTP_SYS_OFFSET_PRECISE as well.
>
> Interesting. I wasn't aware that there is a new ioctl for measuring
> the HW-sys offset. Adding support to chrony shouldn't be difficult.
>
> If I understand it correctly, PTP_SYS_OFFSET can be emulated on top of
> PTP_SYS_OFFSET_PRECISE simply by copying the sys_realtime and device
> fields to corresponding ts slots. The apparent delay will be zero, but
> that's ok if the conversion is really accurate.
Yes, for 1 sample only. Otherwise you'd have the same issue as in
Marcelo's driver (the device aka guest timestamp from
PTP_SYS_OFFSET_PRECISE would not be halfway between the system aka host
timestamps), and your idea below could be applied.
> I'm not sure if trying to do that in the opposite direction is a good
> idea. An application using PTP_SYS_OFFSET_PRECISE may assume the
> conversion is accurate and not include any delay/dispersion in an
> estimate of the maximum error, which is needed in NTP for instance.
>
> If we know the host timestamp ts[1] is not in the middle between the
> guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not
> simply shift ts[1] by (ts[2]-ts[0])/2 ?
Interesting idea! For this to work, KVM needs to implement
getcrosstimestamp and ptp_chardev.c can then add an alternative
implementation of PTP_SYS_OFFSET, based on precise cross timestamps.
Something like
for (i = 0; i <= sysoff->n_samples; i++) {
// ... call getcrosststamp ...
sysns = ktime_to_ns(xtstamp.sys_realtime);
if (i > 0) {
devns = ktime_to_ns(xtstamp.device);
devns -= (sysns - prev_sysns) / 2;
devts = ns_to_timespec(devns);
pct->sec = devts.tv_sec;
pct->nsec = devts.tv_nsec;
pct++;
}
systs = ns_to_timespec(sysns);
pct->sec = ts.tv_sec;
pct->nsec = ts.tv_nsec;
pct++;
prev_sysns = sysns;
}
Marcelo, can you give it a try?
Thanks,
Paolo
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-18 16:00 +0100 |
| Message-ID | <t0ZSq-5mL-15@gated-at.bofh.it> |
| In reply to | #1561839 |
On Wed, Jan 18, 2017 at 03:02:23PM +0100, Paolo Bonzini wrote:
>
>
> On 18/01/2017 14:36, Miroslav Lichvar wrote:
> > On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote:
> >> On 18/01/2017 13:24, Marcelo Tosatti wrote:
> >>>> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating
> >>>> intense interrupts). Follows results:
> >
> >>>> Do you still want to drop it in favour of simplicity?
> >
> >> It's just that it's not obvious why you get better results with biased
> >> host timestamps. What makes the biased host timestamp more precise?
> >>
> >> I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony
> >> does not support it---but I would still prefer you to support
> >> PTP_SYS_OFFSET_PRECISE as well.
> >
> > Interesting. I wasn't aware that there is a new ioctl for measuring
> > the HW-sys offset. Adding support to chrony shouldn't be difficult.
> >
> > If I understand it correctly, PTP_SYS_OFFSET can be emulated on top of
> > PTP_SYS_OFFSET_PRECISE simply by copying the sys_realtime and device
> > fields to corresponding ts slots. The apparent delay will be zero, but
> > that's ok if the conversion is really accurate.
>
> Yes, for 1 sample only. Otherwise you'd have the same issue as in
> Marcelo's driver (the device aka guest timestamp from
> PTP_SYS_OFFSET_PRECISE would not be halfway between the system aka host
> timestamps), and your idea below could be applied.
>
> > I'm not sure if trying to do that in the opposite direction is a good
> > idea. An application using PTP_SYS_OFFSET_PRECISE may assume the
> > conversion is accurate and not include any delay/dispersion in an
> > estimate of the maximum error, which is needed in NTP for instance.
> >
> > If we know the host timestamp ts[1] is not in the middle between the
> > guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not
> > simply shift ts[1] by (ts[2]-ts[0])/2 ?
>
> Interesting idea! For this to work, KVM needs to implement
> getcrosstimestamp and ptp_chardev.c can then add an alternative
> implementation of PTP_SYS_OFFSET, based on precise cross timestamps.
>
> Something like
>
> for (i = 0; i <= sysoff->n_samples; i++) {
> // ... call getcrosststamp ...
> sysns = ktime_to_ns(xtstamp.sys_realtime);
> if (i > 0) {
> devns = ktime_to_ns(xtstamp.device);
> devns -= (sysns - prev_sysns) / 2;
> devts = ns_to_timespec(devns);
> pct->sec = devts.tv_sec;
> pct->nsec = devts.tv_nsec;
> pct++;
> }
> systs = ns_to_timespec(sysns);
> pct->sec = ts.tv_sec;
> pct->nsec = ts.tv_nsec;
> pct++;
> prev_sysns = sysns;
> }
>
> Marcelo, can you give it a try?
Can convert fine, but problem is the simultaneous read
of host and guest clocks.
> Thanks,
>
> Paolo
It seems to me anything else other than using a single TSC read
(for both host and guest clocks) is a poor PTP_SYS_OFFSET_PRECISE
implementation (because it would claim to be similar to ART, where
the timestamps are simultaneous), but not be.
[toc] | [prev] | [next] | [standalone]
| From | Radim Krcmar <rkrcmar@redhat.com> |
|---|---|
| Date | 2017-01-18 16:40 +0100 |
| Message-ID | <t10v7-5P4-13@gated-at.bofh.it> |
| In reply to | #1561873 |
2017-01-18 12:50-0200, Marcelo Tosatti:
> On Wed, Jan 18, 2017 at 03:02:23PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 18/01/2017 14:36, Miroslav Lichvar wrote:
>> > On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote:
>> >> On 18/01/2017 13:24, Marcelo Tosatti wrote:
>> >>>> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating
>> >>>> intense interrupts). Follows results:
>> >
>> >>>> Do you still want to drop it in favour of simplicity?
>> >
>> >> It's just that it's not obvious why you get better results with biased
>> >> host timestamps. What makes the biased host timestamp more precise?
>> >>
>> >> I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony
>> >> does not support it---but I would still prefer you to support
>> >> PTP_SYS_OFFSET_PRECISE as well.
>> >
>> > Interesting. I wasn't aware that there is a new ioctl for measuring
>> > the HW-sys offset. Adding support to chrony shouldn't be difficult.
>> >
>> > If I understand it correctly, PTP_SYS_OFFSET can be emulated on top of
>> > PTP_SYS_OFFSET_PRECISE simply by copying the sys_realtime and device
>> > fields to corresponding ts slots. The apparent delay will be zero, but
>> > that's ok if the conversion is really accurate.
>>
>> Yes, for 1 sample only. Otherwise you'd have the same issue as in
>> Marcelo's driver (the device aka guest timestamp from
>> PTP_SYS_OFFSET_PRECISE would not be halfway between the system aka host
>> timestamps), and your idea below could be applied.
>>
>> > I'm not sure if trying to do that in the opposite direction is a good
>> > idea. An application using PTP_SYS_OFFSET_PRECISE may assume the
>> > conversion is accurate and not include any delay/dispersion in an
>> > estimate of the maximum error, which is needed in NTP for instance.
>> >
>> > If we know the host timestamp ts[1] is not in the middle between the
>> > guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not
>> > simply shift ts[1] by (ts[2]-ts[0])/2 ?
>
>
>
>>
>> Interesting idea! For this to work, KVM needs to implement
>> getcrosstimestamp and ptp_chardev.c can then add an alternative
>> implementation of PTP_SYS_OFFSET, based on precise cross timestamps.
>>
>> Something like
>>
>> for (i = 0; i <= sysoff->n_samples; i++) {
>> // ... call getcrosststamp ...
>> sysns = ktime_to_ns(xtstamp.sys_realtime);
>> if (i > 0) {
>> devns = ktime_to_ns(xtstamp.device);
>> devns -= (sysns - prev_sysns) / 2;
>> devts = ns_to_timespec(devns);
>> pct->sec = devts.tv_sec;
>> pct->nsec = devts.tv_nsec;
>> pct++;
>> }
>> systs = ns_to_timespec(sysns);
>> pct->sec = ts.tv_sec;
>> pct->nsec = ts.tv_nsec;
>> pct++;
>> prev_sysns = sysns;
>> }
Nice. PTP_SYS_OFFSET seems to be mandatory, so this hunk could be
upstreamable as a fallback for PTP devices that have getcrosststamp and
not gettime64. KVM PTP would be the only driver using it so far.
>> Marcelo, can you give it a try?
>
> Can convert fine, but problem is the simultaneous read
> of host and guest clocks.
>
>> Thanks,
>>
>> Paolo
>
> It seems to me anything else other than using a single TSC read
> (for both host and guest clocks) is a poor PTP_SYS_OFFSET_PRECISE
> implementation (because it would claim to be similar to ART, where
> the timestamps are simultaneous), but not be.
Yes, the guest should use the TSC returned by the hypercall to compute
the corresponding guest time, which will allow us to know the
host<->guest offset.
Is this impossible to do with the current API?
Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Date | 2017-01-18 17:00 +0100 |
| Message-ID | <t10Oz-5VY-17@gated-at.bofh.it> |
| In reply to | #1561873 |
On 18/01/2017 15:50, Marcelo Tosatti wrote:
>> Interesting idea! For this to work, KVM needs to implement
>> getcrosstimestamp and ptp_chardev.c can then add an alternative
>> implementation of PTP_SYS_OFFSET, based on precise cross timestamps.
>>
>> Something like
>>
>> for (i = 0; i <= sysoff->n_samples; i++) {
>> // ... call getcrosststamp ...
>> sysns = ktime_to_ns(xtstamp.sys_realtime);
>> if (i > 0) {
>> devns = ktime_to_ns(xtstamp.device);
>> devns -= (sysns - prev_sysns) / 2;
>> devts = ns_to_timespec(devns);
>> pct->sec = devts.tv_sec;
>> pct->nsec = devts.tv_nsec;
>> pct++;
>> }
>> systs = ns_to_timespec(sysns);
>> pct->sec = ts.tv_sec;
>> pct->nsec = ts.tv_nsec;
>> pct++;
>> prev_sysns = sysns;
>> }
>>
>> Marcelo, can you give it a try?
>
> Can convert fine, but problem is the simultaneous read
> of host and guest clocks.
Could the TSC from the hypercall be applied to kvmclock to do this? My
understanding is that get_device_system_crosststamp (which is used in
the sole in-tree implementation of getcrosststamp) already contains all
the logic to do that.
Paolo
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-20 11:40 +0100 |
| Message-ID | <t1ELV-66q-35@gated-at.bofh.it> |
| In reply to | #1561912 |
On Wed, Jan 18, 2017 at 04:45:07PM +0100, Paolo Bonzini wrote:
>
>
> On 18/01/2017 15:50, Marcelo Tosatti wrote:
> >> Interesting idea! For this to work, KVM needs to implement
> >> getcrosstimestamp and ptp_chardev.c can then add an alternative
> >> implementation of PTP_SYS_OFFSET, based on precise cross timestamps.
> >>
> >> Something like
> >>
> >> for (i = 0; i <= sysoff->n_samples; i++) {
> >> // ... call getcrosststamp ...
> >> sysns = ktime_to_ns(xtstamp.sys_realtime);
> >> if (i > 0) {
> >> devns = ktime_to_ns(xtstamp.device);
> >> devns -= (sysns - prev_sysns) / 2;
> >> devts = ns_to_timespec(devns);
> >> pct->sec = devts.tv_sec;
> >> pct->nsec = devts.tv_nsec;
> >> pct++;
> >> }
> >> systs = ns_to_timespec(sysns);
> >> pct->sec = ts.tv_sec;
> >> pct->nsec = ts.tv_nsec;
> >> pct++;
> >> prev_sysns = sysns;
> >> }
> >>
> >> Marcelo, can you give it a try?
> >
> > Can convert fine, but problem is the simultaneous read
> > of host and guest clocks.
>
> Could the TSC from the hypercall be applied to kvmclock to do this? My
> understanding is that get_device_system_crosststamp (which is used in
> the sole in-tree implementation of getcrosststamp) already contains all
> the logic to do that.
>
> Paolo
Yeah feed that TSC to pvclock_clocksource_read.
Cool will take a look at that function thanks.
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-18 15:40 +0100 |
| Message-ID | <t0Zz3-5fK-5@gated-at.bofh.it> |
| In reply to | #1561724 |
On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote: > On 18/01/2017 13:24, Marcelo Tosatti wrote: > > On Wed, Jan 18, 2017 at 10:17:38AM -0200, Marcelo Tosatti wrote: > >> On Tue, Jan 17, 2017 at 04:36:21PM +0100, Radim Krcmar wrote: > >>> 2017-01-17 09:30-0200, Marcelo Tosatti: > >>>> On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote: > >>>>> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2 > >>>>> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on. > >>>>> > >>>>> ts[1] ts[3] > >>>>> Host time ---------+---------+........ > >>>>> | | > >>>>> | | > >>>>> Guest time ----+---------+---------+...... > >>>>> ts[0] ts[2] ts[4] > >>> > >>> KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes > >>> the offset very consistent, so the graph would look like: > >>> > >>> ts[1] ts[3] > >>> Host time -------------+---------+........ > >>> | | > >>> | | > >>> Guest time ----+---------+---------+...... > >>> ts[0] ts[2] ts[4] > >>> > >>> which doesn't sound good if users assume that the host reading is in the > >>> middle -- the guest time would be ahead of the host time. > >> > >> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating > >> intense interrupts). Follows results: > >> > >> Without TSC delta calculation: > >> ============================= > >> > >> #* PHC0 0 3 377 2 -99ns[ +206ns] +/- 116ns > >> #* PHC0 0 3 377 8 +202ns[ +249ns] +/- 111ns > >> #* PHC0 0 3 377 8 -213ns[ +683ns] +/- 88ns > >> #* PHC0 0 3 377 6 +77ns[ +319ns] +/- 56ns > >> #* PHC0 0 3 377 4 -771ns[-1029ns] +/- 93ns > >> #* PHC0 0 3 377 10 -49ns[ -58ns] +/- 121ns > >> #* PHC0 0 3 377 9 +562ns[ +703ns] +/- 107ns > >> #* PHC0 0 3 377 6 -2ns[ -3ns] +/- 94ns > >> #* PHC0 0 3 377 4 +451ns[ +494ns] +/- 138ns > >> #* PHC0 0 3 377 11 -67ns[ -74ns] +/- 113ns > >> #* PHC0 0 3 377 8 +244ns[ +264ns] +/- 119ns > >> #* PHC0 0 3 377 7 -696ns[ -890ns] +/- 89ns > >> #* PHC0 0 3 377 4 +468ns[ +560ns] +/- 110ns > >> #* PHC0 0 3 377 11 -310ns[ -430ns] +/- 72ns > >> #* PHC0 0 3 377 9 +189ns[ +298ns] +/- 54ns > >> #* PHC0 0 3 377 7 +594ns[ +473ns] +/- 96ns > >> #* PHC0 0 3 377 5 +151ns[ +280ns] +/- 71ns > >> #* PHC0 0 3 377 10 -590ns[ -696ns] +/- 94ns > >> #* PHC0 0 3 377 8 +415ns[ +526ns] +/- 74ns > >> #* PHC0 0 3 377 6 +1381ns[+1469ns] +/- 101ns > >> #* PHC0 0 3 377 4 +571ns[+1304ns] +/- 54ns > >> #* PHC0 0 3 377 8 -5ns[ +71ns] +/- 139ns > >> #* PHC0 0 3 377 7 -247ns[ -502ns] +/- 69ns > >> #* PHC0 0 3 377 5 -283ns[ +879ns] +/- 73ns > >> #* PHC0 0 3 377 3 +148ns[ -109ns] +/- 61ns > >> > >> With TSC delta calculation: > >> ============================ > >> > >> #* PHC0 0 3 377 7 +379ns[ +432ns] +/- 53ns > >> #* PHC0 0 3 377 9 +106ns[ +420ns] +/- 42ns > >> #* PHC0 0 3 377 7 -58ns[ -136ns] +/- 62ns > >> #* PHC0 0 3 377 12 +93ns[ -38ns] +/- 64ns > >> #* PHC0 0 3 377 8 +84ns[ +107ns] +/- 69ns > >> #* PHC0 0 3 377 3 -76ns[ -103ns] +/- 52ns > >> #* PHC0 0 3 377 7 +52ns[ +63ns] +/- 50ns > >> #* PHC0 0 3 377 11 +29ns[ +31ns] +/- 70ns > >> #* PHC0 0 3 377 7 -47ns[ -56ns] +/- 42ns > >> #* PHC0 0 3 377 10 -35ns[ -42ns] +/- 33ns > >> #* PHC0 0 3 377 7 -32ns[ -34ns] +/- 42ns > >> #* PHC0 0 3 377 11 -172ns[ -173ns] +/- 118ns > >> #* PHC0 0 3 377 6 +65ns[ +76ns] +/- 23ns > >> #* PHC0 0 3 377 9 +18ns[ +23ns] +/- 37ns > >> #* PHC0 0 3 377 6 +41ns[ -60ns] +/- 30ns > >> #* PHC0 0 3 377 10 +39ns[ +183ns] +/- 42ns > >> #* PHC0 0 3 377 6 +50ns[ +102ns] +/- 86ns > >> #* PHC0 0 3 377 11 +50ns[ +75ns] +/- 52ns > >> #* PHC0 0 3 377 6 +50ns[ +116ns] +/- 100ns > >> #* PHC0 0 3 377 10 +46ns[ +65ns] +/- 79ns > >> #* PHC0 0 3 377 7 -38ns[ -51ns] +/- 29ns > >> #* PHC0 0 3 377 10 -11ns[ -12ns] +/- 32ns > >> #* PHC0 0 3 377 7 -31ns[ -32ns] +/- 99ns > >> #* PHC0 0 3 377 10 +222ns[ +238ns] +/- 58ns > >> #* PHC0 0 3 377 6 +185ns[ +207ns] +/- 39ns > >> #* PHC0 0 3 377 10 -392ns[ -394ns] +/- 118ns > >> #* PHC0 0 3 377 6 -9ns[ -50ns] +/- 35ns > >> #* PHC0 0 3 377 10 -346ns[ -355ns] +/- 111ns > >> > >> > >> Do you still want to drop it in favour of simplicity? > > > > This is the output of "chronyc sources". See section "Time sources" > > of https://chrony.tuxfamily.org/doc/2.4/chronyc.html. > > It's just that it's not obvious why you get better results with biased > host timestamps. What makes the biased host timestamp more precise? The issue is that, without it you have a larger window for interruptions to take place and therefore the read value when ->gettime64 return is from longer time in the past. > I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony > does not support it---but I would still prefer you to support > PTP_SYS_OFFSET_PRECISE as well. Sure, I'll check if it makes sense to implement PTP_SYS_OFFSET_PRECISE for KVM case.
[toc] | [prev] | [next] | [standalone]
| From | Miroslav Lichvar <mlichvar@redhat.com> |
|---|---|
| Date | 2017-01-18 17:00 +0100 |
| Message-ID | <t10Ot-5VY-1@gated-at.bofh.it> |
| In reply to | #1561858 |
On Wed, Jan 18, 2017 at 12:24:09PM -0200, Marcelo Tosatti wrote: > On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote: > > I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony > > does not support it---but I would still prefer you to support > > PTP_SYS_OFFSET_PRECISE as well. > > Sure, I'll check if it makes sense to implement PTP_SYS_OFFSET_PRECISE for > KVM case. But is it really so precise that the application can safely assume there are no errors due to asymmetric delays, etc? I think PTP_SYS_OFFSET_PRECISE should be supported only if the accuracy of the offset measured between the HW and system clock is not worse than the precision of the system clock (typically few tens of nanoseconds). It would be good to verify the accuracy of the offset when the host and guest clocks are synchronised to each other over PTP using two NICs with HW timestamping. -- Miroslav Lichvar
[toc] | [prev] | [next] | [standalone]
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Date | 2017-01-18 17:10 +0100 |
| Message-ID | <t10Ya-6eP-27@gated-at.bofh.it> |
| In reply to | #1561910 |
On 18/01/2017 16:54, Miroslav Lichvar wrote: >> Sure, I'll check if it makes sense to implement PTP_SYS_OFFSET_PRECISE for >> KVM case. > But is it really so precise that the application can safely assume > there are no errors due to asymmetric delays, etc? I think > PTP_SYS_OFFSET_PRECISE should be supported only if the accuracy of > the offset measured between the HW and system clock is not worse than > the precision of the system clock (typically few tens of nanoseconds). > > It would be good to verify the accuracy of the offset when the host > and guest clocks are synchronised to each other over PTP using two > NICs with HW timestamping. PTP_SYS_OFFSET_PRECISE works if the guest can compute its own timestamp based on the same source as the device. On bare metal you have: - the source for system clock is the TSC (with clocksource_tsc) - device provides a (time, ART) tuple You can convert ART->TSC and then ask clocksource_tsc for a system time based on the device-provided ART value. Likewise for KVM: - the source for system clock is the guest TSC (with kvmclock) - host can provide a (time, guest TSC) tuple The PTP driver can take the host-provided guest TSC, and ask kvmclock for a system time based on that TSC value. It's even simpler because there's no ART->TSC conversion involved, and it will always be precise and independent of any vmexit or interrupt delay. Paolo
[toc] | [prev] | [next] | [standalone]
| From | Radim Krcmar <rkrcmar@redhat.com> |
|---|---|
| Date | 2017-01-18 17:20 +0100 |
| Message-ID | <t117P-6i2-1@gated-at.bofh.it> |
| In reply to | #1561910 |
2017-01-18 16:54+0100, Miroslav Lichvar: > On Wed, Jan 18, 2017 at 12:24:09PM -0200, Marcelo Tosatti wrote: >> On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote: >> > I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony >> > does not support it---but I would still prefer you to support >> > PTP_SYS_OFFSET_PRECISE as well. >> >> Sure, I'll check if it makes sense to implement PTP_SYS_OFFSET_PRECISE for >> KVM case. > > But is it really so precise that the application can safely assume > there are no errors due to asymmetric delays, etc? I think > PTP_SYS_OFFSET_PRECISE should be supported only if the accuracy of > the offset measured between the HW and system clock is not worse than > the precision of the system clock (typically few tens of nanoseconds). KVM is actually the perfect user of PTP_SYS_OFFSET_PRECISE: the host and guest system clocks use the same hardware clock. (We want to copy the host data about the clock to the guest, and we just happen to use PTP for that.) > It would be good to verify the accuracy of the offset when the host > and guest clocks are synchronised to each other over PTP using two > NICs with HW timestamping. We can verify the accuracy just by reading the host time and tsc computing guest time from that tsc -- they should be equal. Well, we don't give host frequency to the guest, but I hope that the guest can compute it accurately after polling the host few times. (Still, a room for improvement.) NICs with HW timestamping would be a bit more complicated to set up. :)
[toc] | [prev] | [next] | [standalone]
| From | Marcelo Tosatti <mtosatti@redhat.com> |
|---|---|
| Date | 2017-01-18 15:40 +0100 |
| Message-ID | <t0Zz4-5fK-13@gated-at.bofh.it> |
| In reply to | #1561724 |
On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote: > > > On 18/01/2017 13:24, Marcelo Tosatti wrote: > > On Wed, Jan 18, 2017 at 10:17:38AM -0200, Marcelo Tosatti wrote: > >> On Tue, Jan 17, 2017 at 04:36:21PM +0100, Radim Krcmar wrote: > >>> 2017-01-17 09:30-0200, Marcelo Tosatti: > >>>> On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote: > >>>>> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2 > >>>>> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on. > >>>>> > >>>>> ts[1] ts[3] > >>>>> Host time ---------+---------+........ > >>>>> | | > >>>>> | | > >>>>> Guest time ----+---------+---------+...... > >>>>> ts[0] ts[2] ts[4] > >>> > >>> KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes > >>> the offset very consistent, so the graph would look like: > >>> > >>> ts[1] ts[3] > >>> Host time -------------+---------+........ > >>> | | > >>> | | > >>> Guest time ----+---------+---------+...... > >>> ts[0] ts[2] ts[4] > >>> > >>> which doesn't sound good if users assume that the host reading is in the > >>> middle -- the guest time would be ahead of the host time. > >> > >> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating > >> intense interrupts). Follows results: > >> > >> Without TSC delta calculation: > >> ============================= > >> > >> #* PHC0 0 3 377 2 -99ns[ +206ns] +/- 116ns > >> #* PHC0 0 3 377 8 +202ns[ +249ns] +/- 111ns > >> #* PHC0 0 3 377 8 -213ns[ +683ns] +/- 88ns > >> #* PHC0 0 3 377 6 +77ns[ +319ns] +/- 56ns > >> #* PHC0 0 3 377 4 -771ns[-1029ns] +/- 93ns > >> #* PHC0 0 3 377 10 -49ns[ -58ns] +/- 121ns > >> #* PHC0 0 3 377 9 +562ns[ +703ns] +/- 107ns > >> #* PHC0 0 3 377 6 -2ns[ -3ns] +/- 94ns > >> #* PHC0 0 3 377 4 +451ns[ +494ns] +/- 138ns > >> #* PHC0 0 3 377 11 -67ns[ -74ns] +/- 113ns > >> #* PHC0 0 3 377 8 +244ns[ +264ns] +/- 119ns > >> #* PHC0 0 3 377 7 -696ns[ -890ns] +/- 89ns > >> #* PHC0 0 3 377 4 +468ns[ +560ns] +/- 110ns > >> #* PHC0 0 3 377 11 -310ns[ -430ns] +/- 72ns > >> #* PHC0 0 3 377 9 +189ns[ +298ns] +/- 54ns > >> #* PHC0 0 3 377 7 +594ns[ +473ns] +/- 96ns > >> #* PHC0 0 3 377 5 +151ns[ +280ns] +/- 71ns > >> #* PHC0 0 3 377 10 -590ns[ -696ns] +/- 94ns > >> #* PHC0 0 3 377 8 +415ns[ +526ns] +/- 74ns > >> #* PHC0 0 3 377 6 +1381ns[+1469ns] +/- 101ns > >> #* PHC0 0 3 377 4 +571ns[+1304ns] +/- 54ns > >> #* PHC0 0 3 377 8 -5ns[ +71ns] +/- 139ns > >> #* PHC0 0 3 377 7 -247ns[ -502ns] +/- 69ns > >> #* PHC0 0 3 377 5 -283ns[ +879ns] +/- 73ns > >> #* PHC0 0 3 377 3 +148ns[ -109ns] +/- 61ns > >> > >> With TSC delta calculation: > >> ============================ > >> > >> #* PHC0 0 3 377 7 +379ns[ +432ns] +/- 53ns > >> #* PHC0 0 3 377 9 +106ns[ +420ns] +/- 42ns > >> #* PHC0 0 3 377 7 -58ns[ -136ns] +/- 62ns > >> #* PHC0 0 3 377 12 +93ns[ -38ns] +/- 64ns > >> #* PHC0 0 3 377 8 +84ns[ +107ns] +/- 69ns > >> #* PHC0 0 3 377 3 -76ns[ -103ns] +/- 52ns > >> #* PHC0 0 3 377 7 +52ns[ +63ns] +/- 50ns > >> #* PHC0 0 3 377 11 +29ns[ +31ns] +/- 70ns > >> #* PHC0 0 3 377 7 -47ns[ -56ns] +/- 42ns > >> #* PHC0 0 3 377 10 -35ns[ -42ns] +/- 33ns > >> #* PHC0 0 3 377 7 -32ns[ -34ns] +/- 42ns > >> #* PHC0 0 3 377 11 -172ns[ -173ns] +/- 118ns > >> #* PHC0 0 3 377 6 +65ns[ +76ns] +/- 23ns > >> #* PHC0 0 3 377 9 +18ns[ +23ns] +/- 37ns > >> #* PHC0 0 3 377 6 +41ns[ -60ns] +/- 30ns > >> #* PHC0 0 3 377 10 +39ns[ +183ns] +/- 42ns > >> #* PHC0 0 3 377 6 +50ns[ +102ns] +/- 86ns > >> #* PHC0 0 3 377 11 +50ns[ +75ns] +/- 52ns > >> #* PHC0 0 3 377 6 +50ns[ +116ns] +/- 100ns > >> #* PHC0 0 3 377 10 +46ns[ +65ns] +/- 79ns > >> #* PHC0 0 3 377 7 -38ns[ -51ns] +/- 29ns > >> #* PHC0 0 3 377 10 -11ns[ -12ns] +/- 32ns > >> #* PHC0 0 3 377 7 -31ns[ -32ns] +/- 99ns > >> #* PHC0 0 3 377 10 +222ns[ +238ns] +/- 58ns > >> #* PHC0 0 3 377 6 +185ns[ +207ns] +/- 39ns > >> #* PHC0 0 3 377 10 -392ns[ -394ns] +/- 118ns > >> #* PHC0 0 3 377 6 -9ns[ -50ns] +/- 35ns > >> #* PHC0 0 3 377 10 -346ns[ -355ns] +/- 111ns > >> > >> > >> Do you still want to drop it in favour of simplicity? > > > > This is the output of "chronyc sources". See section "Time sources" > > of https://chrony.tuxfamily.org/doc/2.4/chronyc.html. > > It's just that it's not obvious why you get better results with biased > host timestamps. What makes the biased host timestamp more precise? > > I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony > does not support it---but I would still prefer you to support > PTP_SYS_OFFSET_PRECISE as well. A single TSC read could be used to implement the PRECISE ioctl, but if a timer interrupt takes place on either the host or the guest, and that timer interrupt "adds" the TSC delta to xtime.nsec/xtime.sec, then that single TSC read cannot be used. So you would have to stop timer interrupts (in guest and host) for the duration of the PRECISE ioctl in the guest to avoid that situation, which seems a bit overkill to me. Any other ideas?
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web