On Mon, Jan 28, 2019 at 08:49:31PM -0800, Richard Cochran wrote:
> On Mon, Jan 28, 2019 at 05:24:37PM +0100, Miroslav Lichvar wrote:
> > Add option unicast_max_message_rate to limit the rate of messages
> > generated by the unicast service for all contracts of the port.
> > When a request is receiv
On Mon, Jan 28, 2019 at 09:16:33PM -0800, Richard Cochran wrote:
> On Mon, Jan 28, 2019 at 09:15:00PM -0800, Richard Cochran wrote:
> > I really can't see the point of limiting the duration at all. After
> > all, most networks boot up and run "forever".
>
> And what could be the utility of the al
On Mon, Jan 28, 2019 at 08:46:03PM -0800, Richard Cochran wrote:
> On Mon, Jan 28, 2019 at 07:20:10PM +, Shah, Ashwin (Nokia - US/Sunnyvale)
> wrote:
> > Included is an explanation from Qulsar on why are they adding the
> > additional bytes to the UDP payload.
> > https://qulsar.helpscoutdocs
On Tue, Jan 29, 2019 at 10:00:37AM +0100, Miroslav Lichvar wrote:
> Isn't that negligible when compared to the sync/announce traffic?
Not to the master or to the network itself. I might have 1000 slaves
renewing every 30 seconds.
> The main reason I thought the duration should be limited is clie
Hi,
We are running the old version 1.6.
1. This is a normal FOLLOW-UP received with one-zero padding of 6
octets.
2. sk.c this line returns 64, including eth header size 14.
cnt = recvmsg(fd, &msg, flags);
3. msg.c, cnt is 50, pdulen 44.
m->tlv_count = su
Vincent,
We saw similar issue when co-work with Qulsar's PTP master clock. Qulsar master
clock added 4 extra bytes after the PTP payload in UDP payload. Bad message
error was reported by ptl4l which is running in slave mode. The difference is
that we are using UDP4 unicast rather than ether mul
