On Fri, Dec 26, 2025 at 2:30 PM Jason Wang <[email protected]> wrote: > > On Fri, Dec 26, 2025 at 2:26 PM Jason Wang <[email protected]> wrote: > > > > On Fri, Dec 26, 2025 at 11:15 AM Zhang Chen <[email protected]> wrote: > > > > > > On Fri, Dec 26, 2025 at 9:37 AM Jason Wang <[email protected]> wrote: > > > > > > > > On Thu, Dec 25, 2025 at 6:27 PM Zhang Chen <[email protected]> wrote: > > > > > > > > > > On Thu, Dec 25, 2025 at 3:24 PM Jason Wang <[email protected]> > > > > > wrote: > > > > > > > > > > > > Add test_change_interval_timer to verify that modifying the > > > > > > 'interval' > > > > > > property of filter-buffer at runtime takes effect immediately. > > > > > > > > > > > > The test uses socket backend and filter-redirector to verify timer > > > > > > behavior: > > > > > > - Creates filter-buffer with a very long interval (1000 seconds) > > > > > > - Sends a packet which gets buffered > > > > > > - Advances virtual clock by 1 second, verifies packet is still > > > > > > buffered > > > > > > - Changes interval to 1ms via qom-set (timer should be rescheduled) > > > > > > - Advances virtual clock by 2ms, verifies packet is now released > > > > > > - This proves the timer was rescheduled immediately when interval > > > > > > changed > > > > > > > > > > > > The test uses filter-redirector to observe when packets are released > > > > > > by filter-buffer, providing end-to-end verification of the timer > > > > > > rescheduling behavior. > > > > > > > > > > If user try to simulate network latency by filter-buffer, the accuracy > > > > > of time is important. > > > > > Do we need add some note about the first buffered packet time not > > > > > equel to dynamic > > > > > changed time (default interval time - new qmp cmd effected time + > > > > > changed time ?). > > > > > > > > I'm not sure I will get here, we can't forcast when the first packet > > > > will come. So the behaviour is always that the filter-buffer will > > > > flush at a fixed interval. Or I may miss something here. > > > > > > This case same like this test, before change the user target interval > > > time, > > > filter-buffer maybe already buffered lots of packets, for this parts, the > > > user > > > external measured time did not meet the expected settings. > > > > There's indeed a change of the behaviour, but I'm not sure if there's > > a user that depends on the previous behaviour. > > > > Or if we really care, we need a new attribute. > > Btw, the use case is something like these (out of the scope of COLO). > > Mgmt want to buffer the packets for a while and release the buffered > packets immediately when something happens.
Yes, I know that. And back to COLO, do you think we should change the colo-compare module to a general network comparision module? Any comments about it? Thanks Chen > > Thanks >
