The Finance Act 2015 and proposals in the Finance Bill restrict the tax relief which your company clients may claim in respect of goodwill and certain other customer-related intangible fixed assets. What are the new rules and what action do you need to take?
Measures which were introduced in December 2014 restrict when and how corporation tax relief is allowed in relation to internally-generated goodwill and certain other customer-related intangible assets acquired from connected parties. The new Finance Bill (following the Summer Budget) is set to replace these measures completely.
The existing restrictions apply to goodwill and other relevant assets acquired, on incorporation of a pre-existing business or otherwise, from 3 December 2014 onwards.
The only exception is where the assets were acquired under an unconditional contractual obligation made before that date. The legislation specifies that it applies to acquisitions made directly or indirectly from such related parties from 24 March 2015 onwards unless acquired under an unconditional contractual obligation made before that date (ss.746(2)(ba) , 849B–849D CTA 2009 , as inserted by s.26 FA 2015) .
Pro advice. HMRC may contend that, even before 24 March 2015, the restrictions apply equally to direct and indirect acquisitions.
licences or other rights in respect of such assets ( s.849B(2) CTA 2009 ).
In checking whether the restrictions apply, you have to consider whether or not the transferor had acquired the relevant assets from an unrelated third party.
Where the restrictions don't apply, the transferee company is allowed to claim relief for a proportion of certain debits. These include amortisation and impairment debits that would otherwise have applied under the old (pre- FA 2015 ) rules, provided they were calculated in accordance with GAAP.
In these circumstances the allowable trading debits are D x AM, where D is the amount of the debit that would otherwise have applied, and AM (the appropriate multiplier) is the lesser of 1 and RAVTPA ÷ CEA. RAVTPA is the relevant accounting value of third party acquisitions, and CEA is the expenditure incurred on acquisition of the relevant assets (ss.849C(4) & (6) CTA 2009) .
When the relevant assets are sold, a non-trading debit is recognised equal to D – TD, where D is the amount of the debits that would otherwise have been brought into account and TD is the amount of the trading debits already allowed (ss.849C(5) & (6) CTA 2009) .
Pro advice. An acquisition is not treated as a third party acquisition if its main purpose, or one of its main purposes, is for any person to obtain a tax advantage (s.849B(9) CTA 2009) .
For all other relevant acquisitions on or after 3 December 2014, i.e. those that are not acquired third party assets, no relief is allowed under the intangible fixed assets regime until disposal of the asset. At that point a non-trading debit is recognised, equal to the trading debit that would otherwise have arisen under the old rules ( s.849D CTA 2009 ).
Example 1. On 1 January 2010 QRS, a partnership of individuals, acquired the business and goodwill of P Ltd, a company to whom none of those individuals was a related party. On 1 January 2015 S Ltd, a company related to one of the partners (S), acquired the business and goodwill of QRS. S Ltd has acquired goodwill directly from a related party on or after 3 December 2014, so its trading debits in respect of amortisation, impairment etc. will be restricted. A proportion of the amortisation referable to its acquired third party goodwill (from P Ltd) will be allowed as trading debits. No debits will be allowed in respect of the rest of the goodwill until eventual realisation, at which point only a non-trading debit will emerge.
The new Finance Bill (see Follow up ) replaces these restrictions wholesale and takes matters much further. There is now no relief in respect of all goodwill and other relevant assets (as defined above), unless acquired before 8 July 2015.
Again there is an exception for unconditional contractual obligations made before that date, subject to transitional provisions for accounting periods straddling 8 July 2015. The draft legislation is available as part of the HMRC documents published after the Summer Budget (see Follow up ).
The old provisions are replaced by s.816A CTA 2009 , which will provide (subject to Royal Assent) that no corporation tax deductions are allowed at all in respect of debits discussed above – even if acquired from an unrelated party.
The Finance Bill also amends the treatment of any loss arising on the disposal of any such goodwill and other relevant assets, so that it is deemed to be a non-trading debit arising on disposal.
Example 2. On 1 July 2015 X Ltd acquired goodwill from an unrelated third party at a cost of £100,000. Because the acquisition is from an unrelated party before 8 July 2015, it is unaffected by the FA 2015 changes or the Finance Bill proposals. Under FRS 102 the company decides to amortise the cost on a straight line basis over ten years. The resulting debits will be allowed as trading debits under the intangible fixed assets regime. On 1 August 2015 Y Ltd acquired goodwill from an unrelated third party at a cost of £100,000. Following Royal Assent to the Finance Bill , Y Ltd will be unable to claim any debits in respect of amortisation, impairment, etc. because it acquired the goodwill on or after 8 July 2015. However, if and when the company disposes of the goodwill, it will be entitled to claim a non-trading debit on realisation.
The Finance Bill measures do not impose any restrictions in respect of intangible assets apart from goodwill and the other specified relevant assets. Investment expenditure on intellectual property and other intangible assets will continue to qualify for relief under the intangible fixed assets regime.
Your company clients have been accustomed to obtaining corporation tax relief when expenditure on goodwill and intangible assets is recognised in the accounts.
This relief has been available to companies acquiring a business directly by purchasing its trade and assets, but not to those acquiring shares. The Finance Bill removes this incentive to companies to buy assets rather than shares and helps create a more level playing field.
Pro advice. The dates of transactions need to be carefully noted. The complex, ongoing restrictions on acquisitions from related parties came into effect on 3 December 2014, or perhaps 24 March 2015 in some cases. The much wider restriction proposed by the Finance Bill will take effect from 8 July 2015, subject to Royal Assent.
The changes may well mean that there is little difference between a trade and asset purchase, and a share purchase, at least from the purchasing company's viewpoint. This could well change the approach your client might adopt when selling or purchasing a business.
Corporation tax relief is no longer available where a company acquires goodwill or certain other customer-related intangibles. Inform any clients considering selling or buying a business – it may affect their negotiations in relation to a purchase or sale price, or even the method of purchase or sale.


Casual yet edgy, the Sarina women's boot from Euro Soft will match any Fall ensemble. This silhouette features a faux leather upper with moto inspired buckle detailing for a cool accent. Pair it with your favorite denim and a Fall flannel for a look that stands out.


text:
Tesla to reverse solar price hike for some customers: legal filing
Smith Collection/Gado | Archive Photos | Getty Images
Tesla is trying to placate some solar customers who say they faced sudden price hikes earlier this year, according to new filings with the U.S. district court in San Jose, California.
In a Thursday filing, customers' attorneys wrote, "Tesla informed counsel for Plaintiffs that Tesla had recently launched a program for customers who signed Solar Roof contracts before the April 2021 price changes to return those customers to their original pricing (if they were subject to a price increase in April 2021)."
As of Friday afternoon, further details of this program were not apparent on Tesla's solar websites nor the Engage website for customers and advocates of the company. CNBC reached Tesla's attorneys on Friday to learn more about the program. However, they did not respond to our request immediately.
After suffering unexpected price rises this spring, Tesla solar customers were frustrated and sued.
In three lawsuits, Tesla Solar customer who had previously signed contracts with Elon Musk for his electric car and renewable energy venture was accused of being prepared to have their solar panels installed at home. But they were shocked by unexpected price rises, which required an additional payment to continue with the installations.
It was not an insignificant price increase. According to the lawsuit filings, Matthew Amans saw his price for a solar roof rise to about $146,000 from just $72,000 in his initial contract.
Those lawsuits were later consolidated into Amans v Tesla, Inc.
Tesla hiked prices for its solar installations at least twice early this year, and made it a requirement for customers ordering solar panels or roof tiles to order the Powerwall home energy storage system as well. Later, CEO Elon Musk revealed that the company would not be able to make enough Powerwalls to keep up with demand this year because of the ongoing microchip shortage.
The solar sector is still a small portion of Tesla's overall business. Tesla reported energy generation and storage revenue of $801 million in the second quarter of 2021, with a cost of revenue of $781 million for that division. It does not separate solar revenue. The unit also includes lithium-ion energy storage system revenue. These systems range from small home batteries to large, industrial-scale units.
Comparatively, Tesla recorded $10.2 billion in automobile sales for the same quarter.
This is the legal file:
Consistent Growth despite Challenges By TipRanks
U.S. CBP agency shuts Del Rio border crossing amid influx in migrants By Reuters

redpajama_set_name: RedPajamaCommonCrawl


Following a rigorous selection process and careful review of numerous high-calibre applications, the YWCA Montreal board of directors is pleased to announce the appointment of Mélanie Thivierge as its next CEO.
Ms. Thivierge has extensive management experience in the information sector, having worked for major Quebec media outlets such as Coup de Pouce and Châtelaine magazines, as well as La Presse newspaper, where she is currently chief director of information. Throughout her career, she has shown exceptional skill in leading multidisciplinary teams, managing change, and developing projects. Thanks to her creativity and excellent communication skills, she is sure to succeed in leveraging her expertise to increase the organization's visibility, champion social and gender equality and inclusion, and help reduce violence against women and girls.
Mélanie Thivierge will take up her post on October 30, beginning a transition period alongside the current CEO, Hélène Lépine, who will be retiring at the end of December. She will officially become CEO of the YWCA Montreal on January 1, 2018.


I'm not much for themed reading. My moods are too changeable. I buy a book, plan to read it, but then shove it on my shelf where it'll wither for years before I pick it up again. I think I'm in the mood for fantasy, I pick up a fantasy, and realize what I really want to read is a mystery. I'm reading one book, but read a review for another that sounds better, and then all of a sudden I lose interest in the book I'm currently reading. If I were to stack the books I've finished and then do the same with the books I've not finished, the not finished stack would be twice the size of the finished. I'm a moody person, and my reading reflects my personality.
So, now that I've outed my neurosis, I want to talk about my commitment to reading more books by women in translation, and my participation in August's #WITMonth, or Women in Translation Month.
The Hunger Angel and Secondhand Time are hefty books, so I knew that I wouldn't be able to finish all of these books in one month, but the point of something like Women in Translation Month is not to read books by women in translation for one month a year, and then forget about it; it's meant to expand and enhance our reading habits. Feminism doesn't belong just to western, English speaking women. Feminism is universal, and must be embraced all over the world for true change to ever be accomplished.
I gulped this book down in one sitting, because it was impossible to put down. The book takes place on the island of Mauritius, which is off the east coast of Africa. The book is short. Not quite 200 pages, but it will punch you in the gut. It's about four young adults: Eve, Saadiq, Clelio, and Savita. They're all trapped on the island, desperate to escape, but all ensnared by circumstances beyond their control. They're all wonderfully alive characters. This book is pure poetry (not actual poetry), and if you're into highlighting meaningful passages, well, get a few highlighters ready, because you'll be busy.
Oh lord this book. Like Eve Out of Her Ruins, if you're into highlighting, get ready, because: wow. This was just a perfect book. Noemi Jaffe's mother was a prisoner in Auschwitz, and Jaffe struggles to come to terms with her mother's past without over-dramatizing her experience. As a writer, Jaffe wants a story, but her mother is unable to give her more than the few pages of the diary she wrote right after liberation, so Jaffe spends chapters analyzing different aspects of her mother's meager diary, looking for a key to unlock the inherited suffering she has experienced as a child to a Holocaust survivor.
This book was a huge surprise. I'd never heard of Olga Orozco, but apparently she was a big deal in her home country of Argentina. She's best known as a poet, but her stories were delightful. The best way to describe this book: imagine a whole book written from the perspective of a young Jane Eyre. Intrigued? I hope so.
I'm in love with Svetlana Alexievich. I fell in love with her last year after reading Voices From Chernobyl, and my love has intensified as I've slowly read this book about post-Soviet Russia. Alexievich won the Nobel Prize in Literature in 2015, and her oral histories are some of the most beautiful accounts of tragedy that I've ever read.
I read ten books last month, but the books I read for Women in Translation Month were far superior to anything else. I was so encouraged that I went out and bought more books, which is what Women in Translation month is all about. If you're interested in reading more books by women in translation I would definitely recommend checking out Deep Vellum Publishing and Other Press. They have great titles, and everything I've read from these two indie presses has been top- notch.


The intense training for the Devizes to Westminster Kayaking Marathon is well underway for the Seaford Team. We hear from Charles Lunt on how they are getting on.
Our Debaters and Public Speakers have been busy this term.
Congratulations to all of our Prep School Years 2-5 students for a magnificent Christmas performance of 'Baboushka'. It was simply amazing and all the children performed brilliantly. Thank you to everyone who came along and made the evening so special and for the wonderful costumes.
As part of our Creative Curriculum, the Prep School embarked upon Flight Week. With a range of educational and creative activities, the aim was to lay down conceptual understanding of essential themes required for the curriculum in future education.
During Personal Development time yesterday, our students learnt the true meaning of Ad Alta! They were in awe of Bonita Norris, who came to talk to them about her adventures. Bonita climbed Mount Everest aged only 22 (the youngest British woman at the time) having only discovered a passion for climbing a couple of years before.
She touched upon many powerful messages – taking the first step, the power of the mind to overcome fear, defeating negative spirals of thinking and the joy of sharing tough challenges with other people.
It was a hugely inspirational talk from a fantastic female role model. Thank you Bonita.
Earlier this year we were proud to announce that Alfie Hyde won the Farewell Cup at Cowdray. He was also awarded the Trophy for Most Improved Young Player by the chairman. A fantastic achievement.
Alfie has been playing in competitive tournaments for the last five years. He describes polo as a demanding sport. "I like the intensity" he says.
Old Seafordian, Harry Leleu, features in a BBC article looking at athletes achieving success in sport and classroom.
He tells them "Meeting the demands of studying for a degree in physics is taxing. Marrying that with a grueling training schedule necessary to compete at the top level is therefore only possible with a great deal of focus, organisation and self-discipline, alongside a strong support network.
"With a sport such as triathlon with three disciplines, you can be doing up to 30 hours of training per week, which means time-management is paramount.
"Surrounding myself with like-minded people has a positive impact. Sharing a house with other performance sport athletes means we all study, train, eat and sleep around the clock. We all have a clear understanding of what the other is trying to achieve and we help each other achieve that.
As we welcomed all students back to Seaford Prep at the start of the year they had a fun filled activity week. The exciting induction activities and trips encouraged new friendships and supported the transition to a new school or year group. The activities were designed to help the children get to know one another and to help them adjust to their new classrooms and teachers.
The week started with a Woodland Walk complete with a teddy bears' picnic. The children brought in their favourite teddy or cuddly toy and explored the woods.
The next day those from Years 2 – 5 took part in a circus workshop. They loved every minute and learnt all sorts of new skills. It was fabulous seeing the children working together as they mastered plate spinning, juggling, hula hooping and even stilt walking.
The Classics department at Seaford attended a number of interesting Seminars and Lectures last term, and our Classics teacher Tim Farmer is pleased with the enthusiasm of his students. Year 12 student, Eddie MacKenzie, penned his thoughts for us on some of the recent trips.
Every year, Head of Boarding Matthew Pitteway organises a Santa Dash towards the end of the Winter Term, to raise money for Walled Garden West's charity of the term. This term, it is YoungMinds, and they've currently raised £500.
Matthew reports on today's festive run!
"Nineteen of us set off today on Seaford's annual Santa Dash from Seaford to East Dean. Although the forecast was for 'heavy rain' it was actually dry the whole way round. The ground was very wet though and that was the big challenge this year – dealing with slipping over the whole time.


"Cleveland paramedics, EMTs and dispatchers are fighting the city for post-traumatic stress disorder support in their new contract.
But those negotiations are now on hold.
The city of Cleveland just sent the union a letter asking to throw out an arbitrator ruling, that would have provided them that support."
Most large employers already have an EAP benefit. Makes you wonder if the city considers PTSD services to be in place already. That begs the question, though. What does PTSD support mean?
We have EAP, I believe the union's goal is to have service and support on par with fire and PD as well as PTSD being covered as a duty injury.
I'd heard of similar things when it comes to private services, but not in a municipal service. I did find it humorous that both parties agreed to go to arbitration, and when the arbitrator sided with the union, the city then asked the the union to set aside the arbitrator's ruling.
I also think it's pretty sad that the city "opposes paid leave for mental trauma "due to the difficulties associated with verifying such claims, potential for abuse", yet they have no issues issues with the PD and FD having this protection, nor any documented claims of abuse from the existing city agencies that already have this protection.
I'm curious what the unions next steps will be.
Speaking with the attorney was the last update.
The union has 30 days to make a decision to take this to court and from what I hear when it comes to these sort of issues, the judge typically sides with whatever the arbitrator decided on in the first place. It's just the city and administration of CEMS that are stalling with this. Bottom line to take from this is, the city of Cleveland does NOT care about their public safety employees, especially EMS.
The union has 30 days to make a decision to take this to court and from what I hear when it comes to these sort of issues, the judge typically sides with whatever the arbitrator decided on in the first place.
If your union leadership had any balls, they wouldn't need 30 days to make a decision: it would be "we went to arbitration, and you want the arbitrators ruling put aside because they didn't side with you? Mr. attorney, please file the lawsuit to enforce the arbitrator's ruling, as the city doesn't intend to" It would take 3 days, maybe a week if they wanted a formal vote from the union members. Failing to do this would show extreme weakness on the side of the union.
It's just the city and administration of CEMS that are stalling with this. Bottom line to take from this is, the city of Cleveland does NOT care about their public safety employees, especially EMS.
The story behind it was that the city and our OWN commissioner of EMS had 90 days to make the decision to appeal what the arbitrator ruled or vacate the arbitration from September to December 17th at 5pm, and our commissioner chose to vacate the arbitration at 4pm on December 17th. So our union is going to play the game of waiting until the last possible second to file their appeal and take this to court. There's obviously a lot of problems between our own commissioner (a convicted felon in the state of Illinois) and our union (us field, dispatch, and office personnel).
In the contract also, it not only included agreements to PTSD support for our personnel, but also our raises, our retro pay in which each of the approximate 300 employees is owed an average of 5 grand a person, activating our Star Days which is like a Kelly Day for firemen (paid day off every few weeks) as of right now our Star Days are paid out as opposed to getting the day off, and our dispatchers would get 12 hour shifts instead of 8 hour shifts.
The contract also limited our commisioner's management abilities too.
The story behind it was that the city and our OWN commissioner of EMS had 90 days to make the decision to appeal what the arbitrator ruled or vacate the arbitration from September to December 17th at 5pm, and our commissioner chose to vacate the arbitration at 4pm on December 17th.
yeah, that's pretty shady, but don't forget, your commissioner IS the city, or more accurately, a person appointed by the mayor. He is looking out for the mayor's best interests, not yours. He might be the appointed boss, and sometimes might be liked by the people under him, but he isn't always going to be looking out for your best interests.
So our union is going to play the game of waiting until the last possible second to file their appeal and take this to court. There's obviously a lot of problems between our own commissioner (a convicted felon in the state of Illinois) and our union (us field, dispatch, and office personnel).
That's a stupid game; the only people who lose are the field staff who are unable to get the services. I can assure you, the city isn't losing sleep over some unhappy EMS workers.
The most recent collective bargaining agreement between Cleveland EMS and the city expired in April 2016, Paul Melhuish, president of CARE 1975, told EMS World. This arbitration award is for the current contract, which would expire April 1, 2019. "By filing in the court of appeals to vacate the award, [the city] could delay this contract up to two more years (assuming all appeals are used), as well as the next contract," Melhuish said.
So is the PTSD support really the main sticking point here, or is that just one issue out of many in a contract that the two sides can't agree on?
It's just one issue out of many. The other issues include raises, retro pay, star days (a paid day off every few weeks), and a no fault sick policy.
That's what I figured. So basically the news article was completely misleading.
Leave it to the unions to lie to the public and the media to go right along with it.


Our microbiota is a complex community of organisms working together to maintain dynamic ecological balance. Of the trillions of bacteria that inhabit the human body, 80% live in the gut. These bacteria are not only essential for normal GI function, but also for systemic processes, brain development and function, behaviour, and cognitive and emotional processing.


School may be out for the summer, but some local tweens engaged in their own lessons of charity.
Instead of spending time at the pool or playing video games, some of the youngest members of St. Stephen's United Methodist Church raised $400 for the children of families residing in housing provided by Good Shepherd Housing as part of a week-long Mission Possible Kids Camp developed and led by the Rev. Abi Foerster.
The church group, comprised of rising fourth to seventh grade students, earned money via a car wash, then purchased bags and the supplies to fill them with for 12 kids living in Good Shepherd Housing apartments. "Children are never too young to learn the importance of serving others and when given the opportunity can often achieve what many adults might deem the impossible," says Rev. Foerster.
a plush toy hand-made by the campers.
"It's heartwarming and inspiring to work with students striving to help others in their community," says GSH President David Levine.


text:
The Galapagos Islands
The Galápagos Islands are an archipelago of volcanic islands distributed around the equator in the Pacific Ocean, 972 km (525 nmi) west of continental Ecuador, of which they are a part. It is a UNESCO World Heritage site: wildlife is its most notable feature.
The islands are geologically young and famed for their vast number of endemic species, which were studied by Charles Darwin during the voyage of the Beagle. His observations and collections contributed to the inception of Darwin's theory of evolution by natural selection.
A Sea Lion Pup nursing on Isla Isabela in the Galapagos Islands.
A rare Fur Sea Lion sleeping in the Galapagos Islands.
A Marine Iguana and a Fur Sea Lion on Isla Isabela in the Galapagos Islands.


text:
Q: Reversing a linear regression -- theoretical case Suppose I fit a linear model where Y ~ X1 + X2 + error. This model performs quite well. Now suppose I want to reverse this and estimate X1 and X2 given that I have observed Y.
I'm curious what is the most appropriate way to do this? Is it fitting two regressions where one of the variables (either X1 or X2) is latent? Is it some sort of parameter grid search where I have X1 ~ Y + X2 for a fixed X2 and I do a grid search over X2?  (and then I reverse it and do the same for X1)?
Thank you for your suggestions!

A: In the generality that you described, this is a problem about estimating the joint distribution of X1, X2 and Y. Depending on the data size, you can do this either parametrically (medium-to-large sample size) or nonparametrically (large sample size). All conditional means will come as an easy follow-up calculation. You may notice that they are not linear. So linear regression may or may not be suitable here.

redpajama_set_name: RedPajamaStackExchange


text:
\section{Conclusion}
The previous sections have given an overview of the ESS software architecture
for event processing in general and as implemented in four detector designs specifically.
We have discussed the technology choices made and the toolchain used
for software development. Finally we presented recent \red{event processing rates} for four
detectors which will be used in ESS instruments.

  We have shown an architecture that can be scaled up to deal with the
high neutron rate ESS will deliver. Without having spent much time on optimisation
of the code so far we have achieved high event processing rates of the order of
1 to 25 M events per second, and have shown how this can be scaled to much higher
\red{event rates} using commodity hardware. The detectors \red{discussed in this paper represent
the range of the expected processing requirements foreseen at ESS, from simple to quite complex.}
The toolchain
does not wait to become operational after 2021 where ESS is expecting see first beam on target,
but is in actual use for data acquisition as the detector development continues.

Most detectors are constructed by the tiling of identical and independent units. Scaling the
processing up for these are easy as we can employ multiple event formation units running
in parallel.

Not all scalability problems have been solved yet, however. Future work will focus
on scaling the Gd-GEM processing as it is markedly more complicated than the other detectors.
For example a simple partitioning of the detector surface may not \red{be feasible},
because the charge tracks from a single neutron conversion
can easily cross partition borders. Collaboration on this
topic has already started. Work will also
be done on deploying multiple processing pipelines on a multi-core CPU, where typically
resource sharing problems, such as memory and network bottlenecks, will become more pronounced
than observed so far.

\acknowledgments
This work is funded by the EU Horizon 2020 framework, BrightnESS project 676548.
Ramsey Al Jebali would like to acknowledge partial support from the EU Horizon 2020 framework,
SoNDe project 654124.
  The authors would like to acknowledge the provision of beam time from R2D2 at IFE(NO), CT1 at ILL(FR),
CRISP at ISIS(UK) and the Source Testing Facility at Lund University(SE).

\vspace{5mm}
\noindent
We would also like to thank Matthew Jones, software consultant at ISIS, for his contributions on Kafka
and Google FlatBuffers.
  Finally we would like to acknowledge Kalliopi Kanaki and Irina Stefanescu, Detector Scientists at
ESS, for their comments and suggestions for improvements.

\input{sec_bibliography.tex}

\section{Detector readout}
\label{sec:readout}
The subject of this report is mainly concerned with the detector data flowing from
the readout system backend to and through the event formation system. Due to
the high neutron flux delivered by ESS, the data rates will be correspondingly high. The ESS
readout system conceptually consists of a detector specific front end and a generic backend as illustrated
in \red{figure} \ref{fig:ess_readout}.

The back end
connects to the event formation system via 100~Gb/s optical Ethernet links, which
provide more capacity than required for most instruments. However,
for the small scale detector prototypes we typically use Gigabit Ethernet.

The ESS readout system is currently under development. Until it becomes generally
available a number of different ad-hoc readout systems have been employed
for testing of prototypes. The ones relevant
for this report are: CAEN, mesytec, RD51 Scalable Readout System and ROSMAP-MP from
Integrated Detector Electronics AS
\cite{caen, mesytec, srs, ideas}.
These are either controlled by applications supplied by the manufacturer, by
custom Python scripts or GUI applications. The digitised data is transmitted as binary
data over UDP in a similar way as when the instruments are in operation.
None of these ad-hoc systems is currently set up to consume the ESS absolute timing information.

\begin{figure}[tbp]
  \centering
  \includegraphics[width=0.7\textwidth,clip]{figures/ess_readout.png}
  \caption{High level architecture of the ESS readout system.}
  \label{fig:ess_readout}
\end{figure}

\subsubsection*{Digital geometry}
While the common readout back-end deals with the connection to the event formation,
different detector technologies have different electrical connections to the readout
front ends. Multi-Grid for example, uses a combination of wires and grids whereas Multi-Blade uses
wires and strips. Even for a specific detector technology, the different prototypes can have different sizes
and therefore different number of channels.
We need to combine the knowledge about the electrical wiring and how the digitisers
are connected in order to know anything about where on the detector a signal was induced. We call
this the digital geometry.

An example outlining the digital geometry for Gd-GEM is shown in
figure \ref{fig:gdgem_digital_geometry}. The x-position is a function $x(a, c, f)$ of an \textbf{asic id}
ranging from 0 to 1, a \textbf{channel} from 0 to 63 and a \textbf{front end card id} from  0 to 9.
  For each detector pipeline, a digital geometry C++ class is created
to handle this mapping. The classes are typically parametrised so they can handle multiple variants.
\begin{figure}[tbp]
  \centering
  \includegraphics[width=1.00\textwidth,clip]{figures/gdgem_digital_geometry.png}
  \caption{\label{fig:gdgem_digital_geometry} An example of a possible mapping of the digital
  geometry for x-strips for Gd-GEM. Strip 1 corresponds to asic 0, channel 0, front end card id 0 and strip
  1280 to  asic 1, channel 64, front end card id 9.}
\end{figure}

\subsubsection*{Logical geometry}
The main end result from the event formation are event tuples. An event tuple (t,p) consists of
a timestamp and a pixel\_id. Due to its physical construction, the detectors are inherently
pixellated and what we calculate is simply which pixel was hit by a neutron, i.e. this
step does not need to know anything about the physical size or absolute compositions
of the pixels. We call this the logical geometry, \red{the principle is illustrated in figure \ref{fig:logical_geometry}.}
\begin{figure}[htbp]
  \centering
  \includegraphics[width=.4\textwidth,clip]{figures/logical_geometry.png}
  \caption{Logical geometry convention for 3D detectors. The example shows a single-panel 3D
    detector geometry with dimensions nx, ny, nz = (5,4,2), and pixel id's from 1 to 40.}
  \label{fig:logical_geometry}
\end{figure}
We have defined a common
convention for the logical geometry for ESS instruments. The convention covers
single-panel and multi-panel, 2D and 3D detectors. For example Multi-Grid is a
single panel 3D detector (which then has voxels instead of pixels, but we do not
make a distinction) and Gd-GEM is a multi-panel 2D detector. In this scheme we
also unambiguously define the mapping between the (x,y,z) coordinates of the (logical) positions
and a unique number, called the pixel\_id.

\section{Four ESS detector technologies}
\label{sec:detectors}
Neutrons cannot be directly observed, but are observed as
the result of a conversion event where the neutron interacts
with a material with a high thermal neutron cross section for absorption. In
this process the absorber material converts the neutron into charged particles
or light, which can then be detected by conventional methods. For the
detectors in this study the conversion materials are based on
$\isotope{Li}$, $\isotope{Be}$ and $\isotope{Gd}$. The detection methods for
the individual detectors will be described below.

\section{Event Formation Unit architecture}
\label{sec:efu}

The EFU architecture, illustrated in figure \ref{fig:efu_architecture}, consists of a main application
with common functionality for all detectors and detector-specific processing pipelines.
  The software is written in C++, and is built using gcc and clang compilers for Ubuntu, macOS and CentOS.
CentOS is currently the target Linux distribution for ESS operations, whereas the other operating systems
are used during development and implementation.

 The main application handles low CPU-intensity tasks such as launch-time configuration via command-line
options, run-time configuration using a TCP-based command API, application state logging and periodic
reporting of run time statistics and counters.

  Detector pipelines are responsible for handling realtime readout data,
and must conform to a common software interface definition. The pipelines are implemented
as shared libraries that are loaded and launched by the main application as
POSIX threads with support for thread affinity, which fixes a thread onto a specific processor core.
  The plugin must specify at least one processing thread but apart from this
no further restrictions are imposed. We have experimented with different
configurations for different detectors, but currently the number
of threads in a detector pipeline ranges from one to three.

When more than one thread is
in use, the data is shared between the producer and the consumer thread by a circular data buffer
(FIFO) which preserves the order of the arriving data. The FIFO is based on pre-allocated memory to
avoid unnecessary data copying and C++ \textbf{std::atomic}
primitives for resource locking. For performance benchmarking
we use the \textbf{rdtsc()} instruction call, which
gives a high resolution timestamp counter with low latency.

\begin{figure}[tbp]
  \centering
  \includegraphics[width=.95\textwidth,clip]{figures/efu_architecture.png}
  \caption{\label{fig:efu_architecture} Event Formation Unit (EFU) architecture.}
\end{figure}
The data processing part of the detector pipelines generally consists of a tight loop with a BSD socket
\textbf{recvfrom()} system call, a \textbf{parse()} function, and a \textbf{produce()} step. These
processing steps can be done in a single or multiple threads, depending on specific requirements.

\input{sec_udpperf.tex}

\subsection{FlatBuffers/Kafka}
The output of the EFU is a stream of events. We have chosen
Apache Kafka \cite{kafka} as the central technology for transmission, and Google FlatBuffers
\cite{flatbuffers} for serialisation.
Apache Kafka is an open source software project for distributed data streaming. Multiple Kafka brokers form a
scalable cluster,
which supports a publish-subscribe message queue pattern with configurable data persistence.

In Kafka, producers send data to a topic in a cluster. A consumer subscribes to a topic to receive messages,
either from the instant the subscription starts or from a previous offset, provided the requested data is
still available in storage on the cluster, given a retention policy. Consumers may also be grouped to
distribute the processing load among different processes.

Both producers and consumers can be developed using
open source Kafka client libraries. The EFU uses \textbf{librdkafka} \cite{librdkafka}, which offers a C/C++ API.
While Kafka offers a scalable and reliable transmission of arbitrary data, FlatBuffers provides a schema-based
event serialisation method, and a mechanism for forward and backward compatibility of the schemas.
Figure \ref{lst:schema} shows the currently used schema for events.

\begin{figure}
  \lstset{basicstyle=\small\ttfamily, xleftmargin=.15\textwidth, xrightmargin=.15\textwidth}
  \begin{lstlisting}[frame=single]
include "is84_isis_events.fbs";

file_identifier "ev42";

union FacilityData { ISISData }

table EventMessage {
    source_name : string;
    message_id : ulong;
    pulse_time : ulong;
    time_of_flight : [uint];
    detector_id : [uint];
    facility_specific_data : FacilityData;
}
root_type EventMessage;
  \end{lstlisting}
  \caption{The ESS FlatBuffers event schema. The main fields of relevance are the arrays
    \textbf{time\_of\_flight} and \textbf{detector\_id} (from \url{https://github.com/ess-dmsc/streaming-data-types}).}
  \label{lst:schema}
\end{figure}

\subsection{Live detector data visualisation }
After writing the first prototype for event formation, it became clear that it would
be beneficial to also use the EFU as a DAQ system for early detector experiments and
commissioning. One of the easiest ways to validate the event processing
is to visualise the detector image and other relevant data, such as channel intensities
and ADC distributions.

For this reason the EFU also publishes such information via Kafka, and
an application named Daquiri was written for visualising these data. Daquiri
subscribes to Kafka topics, collects statistics, and provides plotting functionality, and
is planned to be an integral part of the software bundle developed for ESS operations.
The Daquiri GUI is based on Qt \cite{qt1} and is highly configurable in terms of available plotting formats,
the dashboard configuration, labels, axes, colour schemes, etc.
\red{A typical screenshot is depicted in figure \ref{fig:daquiri}.}
Daquiri is open source software \cite{daquiri1}.

\begin{figure}[tbp]
  \centering
  \includegraphics[width=.95\textwidth,clip]{figures/daquiri.png}
  \caption{\label{fig:daquiri} The Daquiri commissioning tool.}
\end{figure}

\subsection{Runtime stats and counters}
The availability of relevant application and data metrics is essential for both early prototyping
and easy monitoring while in operation, for example incoming packet rates, parsing
errors, calculated events, discarded readouts, etc. The detector API provides a mechanism
for the detector plugin to register a number of named 64-bit counters. These are then periodically
queried by the main application and reported to a time-series server.

We have
chosen Graphite as the time-series server \cite{graphite1} technology and use Grafana \cite{grafana1}
for presentation. Graphite has a simple API for submission of data, which consists of
a hierarchical name such as \emph{efu.net.udp\_rx}, a counter value and a UNIX timestamp.
\begin{figure}[tbp]
  \centering
  \includegraphics[width=1.0\textwidth,clip]{figures/grafana_multiblade.png}
  \caption{\label{fig:grafana_multiblade} Grafana dashboard used \red{for monitoring packet
  and event related counters for} an implementation of Multi-Blade data processing.}
\end{figure}
The combination Grafana/Graphite has proven to be very useful, not only for monitoring the event processing
software.
 Scripts have been written to check Linux kernel and network card counters, as well as
disk and CPU usage, all of which are relevant when running at high data rates while simultaneously writing
raw data to disk. We typically
publish monotonically increasing counter values, and then use Grafana to transform these into
rates. We plan to offer Grafana/Graphite for the software we are developing for ESS operations.
\red{Figure \ref{fig:grafana_multiblade} shows how this currently looks like.}

\subsection{Trace and logging}
For application logging we have chosen Graylog \cite{graylog1}. In the EFU, Graylog is used for low rate
log messages. We use the \textbf{syslog} \cite{syslog} conventions for logging levels and severities.
Graylog is not currently in wide use in the infrastructure, but will be essential for monitoring the ESS data
processing chain once in operations, when multiple EFUs are deployed.

During development we use a simple but effective
trace system consisting of groups and masks. These currently print directly to the console, which
is extremely detrimental to performance when operating at thousands of packets and millions
of readouts per second. Therefore, we made the trace macros configurable at compile time,
so that no overhead occurs when they are not needed. Both the log and trace system accept
log messages in a \textbf{printf()}-compatible format using variable arguments.

\subsection{Software development infrastructure}
All the software components that are part of the data aggregation and streaming pipeline
are being developed collaboratively by the partners as open source projects released
under a BSD license. Git \cite{git} is used for version control and all software is available for public
scrutiny on GitHub \cite{github}. We use Conan \cite{conan} as our C++ package manager and CMake
\cite{cmake} for multi-platform Makefile generation. The projects are built with gcc and clang
compilers \cite{gcc, clang}.

  A Jenkins \cite{jenkins} build server automatically triggers builds and runs commit stage tests each time
new code is pushed to a repository: Every commit on every branch for every project triggers
a Jenkins build and test cycle on multiple operating systems providing rapid feedback on breaking
changes.
  The tests that are run vary according to the application but for C++ code in general include unit
tests with Google Test \cite{googletest}, static analysis with Cppcheck \cite{cppcheck}, and test
coverage reports with gcovr \cite{gcovr}.  We also check for code format compliance with clang-format
\cite{clangformat}, and memory management problems with Valgrind \cite{valgrind}.

  Individual methods and algorithms can
be benchmarked for performance with Google Benchmark \cite{googlebenchmark}.
  The executables generated from every successful build cycle are saved as artefacts and can thus be used for
quick deployment or integration testing. Configuration of the machines in the build and test environment
is done using Ansible \cite{ansible}, with the scripts kept under version control.

\section{Introduction}
The European Spallation Source \cite{ess1, ess2} is a spallation neutron source currently being built
in Lund, Sweden.  ESS will initially support 15 different instruments for neutron scattering.
The ESS Data Management and Software
Centre (DMSC), located in Copenhagen, provides infrastructure and computational support for the acquisition,
event formation, long term storage, and data reduction and analysis of the experimental data.
At the heart of each instrument is a neutron detector and its associated readout system. Currently detectors as
well as readout systems are in the design or implementation phase and various detector prototypes
have already been produced \cite{sonde1, multigrid1, multiblade1, gdgem1}. ESS detectors will operate in event
mode\cite{gahl}, meaning that for each detected neutron a (time, pixel) tuple is calculated, providing the detection
timestamp (with a resolution of 100 ns or better) and position on the detector where the neutron hit. This allows for later filtering of individual events (vetoing) and flexible refinement of the energy determination as well as of the scattering vector.

ESS detector prototypes have been tested at various neutron facilities
and a number of temporary data acquisition systems have been in use so far.
When in operation, ESS will use a common readout system which is currently being
developed \cite{kolya1}.
We are also moving towards a common software platform for the combined activities of data acquisition
and event formation. This platform consists of core software functionality common to all detectors and a
detector specific plugin architecture.

The main performance indicators of the system are: the neutron rates, the data
transport chain from the front-end electronic readout to the event formation system, the parsing requirements
for the readout data, and the individual data processing requirements for the different detector technologies.

Good estimates of the neutron flux on the sample and the detectors have been produced by
simulations \cite{simtools, irina, kelly}, and estimates on the corresponding data rates
have been made, although the precise values will depend upon engineering design decisions that
are still to be made or further detector characterizations. Examples of these are: number of triggered
readouts per neutron, readout data encapsulation methods, hardware data processing, etc.

\red{
The architecture for the ESS data path is described in section \ref{sec:essarch}, and
section \ref{sec:readout} briefly describes ESS readout architecture
and discusses hardware and physical abstractions such as digital and logical geometry.
  Parsing of readout data and
event formation processing is the subject of section \ref{sec:detectors}, which
describes four detectors (sections \ref{sec:sonde} - \ref{sec:gdgem}), which
have been subjected to early testing at neutron sources
using a scaled-down version of the anticipated software infrastructure for ESS operations.
The software architecture is described in section \ref{sec:efu}, where the choice and
performance of UDP for detector readout is discussed in section \ref{sec:udpperf}.
}

\red{Throughput rates} for event processing are reported in section \ref{sec:performance}.

\subsection{Instrument data rates}
ESS is a spallation source, where neutrons are generated by the collision of high energy protons with a
suitable target -- tungsten in case of ESS.
The proton source is pulsed, with a 14 Hz frequency. The neutron flux generated by
this process has been simulated with MCNP from the target/moderator \cite{mcnp, mcnpb, moderator}.
The flux is reduced throughout the neutron path by neutron transport components (neutron guides,
monitors, beam ports) and instrument-specific components (collimators, choppers, sample
enclosures, etc.) and are typically calculated using the  Monte Carlo simulation tool
McStas \cite{mcstas, mcstasb}. The detector properties are determined by a combination of Geant4 simulations
\cite{geant4, geant4b, geant4c} for the initial considerations and experiments at neutron facilities
once a prototype has been built.

  Typically, rates are reported for neutrons hitting the sample and the detector, as
shown in table \ref{tab:instrument_rates}.
  As mentioned, these rates are not directly convertible into data rates received by the software. Our estimates
of the required processing power are, however, based on neutron rates for the detector surface assuming
100\% efficiency. On the input side of software processing we use the peak instantaneous rate, measured as the
highest number of neutrons received in a 1~ms time bin \cite{irina}, because we must receive all data without loss.
On the output side, we use average rates because event data is buffered up for transmission inside the event
formation system which has the practical effect of load levelling the event rate with time.

\begin{table}[tbp]
  \footnotesize
  \centering
  \caption{\label{tab:instrument_rates} Current estimates of data rates for selected ESS instruments
    at 5MW ESS source power. Global avg. rate is defined in \cite{irina}. Data Rate is the corresponding
    amount of data received for software processing.}
  \smallskip
  \begin{tabular}{llcccc}
    \Xhline{2\arrayrulewidth}
      \textbf{Instrument} &  \textbf{Detector}   & \textbf{Flux on sample}   &\textbf{Global avg. rate}  & \textbf{Data Rate} \\
                 &             &  [$\mathrm{n/s/cm^2}$ ]    &   [MHz]     &  [MB/s]   \\
    \hline
      C-SPEC             & Multi-Grid  & $10^8$      &   10    &     80  \\
      ESTIA              & Multi-Blade & $10^9$      &  500    &   4000  \\
      FREIA              & Multi-Blade & \e{5}{8}    &  100    &    800  \\
      LoKI\footnotemark  & BAND-GEM    & $\leq 10^9$ &   34    &    272  \\
      LoKI               & BCS         & $\leq 10^9$ &   37    &    298  \\
      NMX                & Gd-GEM      &\e{4.8}{8}   &    5    &    300  \\
      SKADI              & SoNDe       & $\leq 10^9$ &   37    &   1180  \\
      T-REX              & Multi-Grid  & $10^8$      &   10    &     80  \\
    \Xhline{2\arrayrulewidth}
  \end{tabular}
\end{table}
\footnotetext{The detector technology for LoKI has not been finally decided.}

\subsection{State of the art}
\red{At most existing neutron facilities, the data acquisition is highly beam line specific, and based around the DAQ PC on the beamline, as the instrument
control and DAQ PC, for example} \cite{IBR2-DAQ}. \red{It can not be seen as an integrated system at the facility level. Part of the reason for this is to be able
to continue operation of legacy systems. Additionally this is the simplest approach to DAQ.}

\red{Starting with ISIS, there have been moves to integrate the DAQ more at the facility level} \cite{ISIS-DAE2, ISIS-DAE2_II}. \red{More recently, the ILL has been investigating
moving some of the data reduction and processing into the online data acquisition and control} \cite{ILLDAQ}. \red{The SNS started with a DAQ system that used a
in-house custom code for instrument control and data acquisition} \cite{SNS-DAS}. \red{More recently, the SNS has upgraded most beam lines with a more integrated
and standardised DAQ and controls system. The new DAQ is controlled by EPICS directly} \cite{SNS-DAQ}.

\red{One particular feature of ESS instruments is that for the detector systems there is a dramatic increase in channel count. Typical DAQ systems for neutron
instruments at existing facilities have less than 1000 electronics channels. ESS instruments will in general have >1000 electronics channels, with some
instruments being in the 10 000- 100 000 electronics channels range. This means that a fully integrated DAQ system is needed. Additionally, the increase
in capability for networking, processing and data handling, means that many operations and algorithms that would only have been possible to do previously
either offline, after data storage, or in dedicated fast electronics, can now be done in realtime with sufficiently low latency in a single or small cluster
 of PCs} \cite{CMS-DAQ,ZEUS-GTT}. \red{The architecture foreseen for the ESS data acquisition, described in this paper, takes advantage of this capability.}

\subsection{Architecture for the ESS data path}
\label{sec:essarch}
The system architecture for the ESS neutron data path is shown in figure \ref{fig:ess_data_path}.
Every neutron scattering instrument has at least one detector: the individual
detector technologies vary \cite{kirstein}, and this is discussed in section \ref{sec:detectors}, but eventually an
electric signal is induced on an electrode. This signal is digitised by the readout electronics and
sent via UDP to the event formation system.

  The key component for the software event formation system is the Event Formation Unit (EFU), a user-space Linux
application targeted to run on Intel x86-64 processors written in C++. For each ESS instrument, several EFUs will
run in parallel to support the high data rates.
  The EFU is responsible for processing the digitised readouts and converting these into
a stream of event (time, pixel) tuples.

The event tuples are serialised and
sent to a scalable data aggregator/streamer providing a publish/subscribe
interface. A file writer application subscribes to the neutron data stream and
streams from other sources such as motor positions for collimators and sample, temperature,
pressure, magnetic/electric fields, etc. This aggregated data is then written to file in a format
suitable for long-term storage. From permanent storage
it is then possible to perform offline data reduction and analysis \cite{afonso}.
\red{The data streams are not only available to file writing, but will also be used
for live data reduction by Mantid \cite{mantid}.}

\begin{figure}[tbp]
\centering
\includegraphics[width=1.0\textwidth,clip]{figures/ess_data_path.png}
\caption{\label{fig:ess_data_path} ESS data path.}
\end{figure}

\section{\red{Event processing rates}}
\label{sec:performance}

The key metric we use for the evaluation of performance is the number of events the detector
pipeline can process per second. To benchmark this, we use detector data recorded as
Ethernet/UDP packets in an number of measurement campaigns.
This data is then sent to the event formation system as fast as
possible and the achieved rates are retrieved via Grafana.

  The setup uses three servers: a macOS laptop acting as a data generator/detector readout, a Ubuntu
workstation hosting the EFU and Kafka, and another Ubuntu workstation which hosts Graphite and Grafana metrics.
  The hardware specifications are listed in table \ref{tab:perf_setup}. The tests were made on the latest event
formation software \cite{efugit}. For Gd-GEM we have implemented a performance test
based on Google Benchmark, which directly targets the event processing algorithm,
and is likely to present an upper bound for the \red{event rates} in a single processing thread
as there is no other overhead involved.

\begin{table}[tbp]
  \footnotesize
  \centering
  \caption{\label{tab:perf_setup} Machine configurations for the performance test setup.}
  \smallskip
  \begin{tabular}{llll}
    \Xhline{2\arrayrulewidth}
      \textbf{Machine}     & \textbf{OS} & \textbf{CPU} & \textbf{RAM} \\
    \hline
          detector         &  macOS 10.13.3     &  Intel Core i7 @ 2.2 GHz          &  16 GB, DDR3, 1600 MHz  \\
          efu              &  Ubuntu 16.04      &  Intel Xeon E5-2620 v3 @ 2.40GHz  &  64 GB, DDR4, 2133 MHz  \\
          metrics          &  Ubuntu 16.04      &  Intel Xeon E5-2620 v3 @ 2.40GHz  &  64 GB, DDR4, 2133 MHz  \\
          benchmarks       &  Ubuntu 16.04      &  Intel Core i7-6700    @ 3.40GHz  &  32 GB, DDR4, 2133 MHz  \\
    \Xhline{2\arrayrulewidth}
  \end{tabular}
\end{table}

Table \ref{tab:performance} summarises the results of the performance measurements. It shows that a
pipeline can support the reception and processing of around 85.000 UDP packets per second and
several millions readouts per second using one or two CPU cores. The reported event rates
reflect the amount of computational work that has to be performed on the data: Gd-GEM has the most
complex algorithm, Multi-Grid and Multi-Blade have medium complexity, and SoNDe requires the least
processing.

\begin{table}[tbp]
  \footnotesize
  \centering
  \caption{\label{tab:performance} Measured performance for detector pipelines. }
  \smallskip
  \begin{tabular}{llccccc}
    \Xhline{2\arrayrulewidth}
      \textbf{Detector} &  \textbf{Machine}     & \textbf{Packet Rate} & \textbf{Trigger Rate} & \textbf{Event Rate} & \textbf{Cores} &\red{\textbf{Packet size}} \\
                        &                       &      [ pkt/s ]       &     [readouts/s]      &   [events/s]        &       & \red{[bytes]} \\
    \hline
          Gd-GEM        &  benchmarks           &  n/a                  &      18.6 M          &   500 k -- 1 M      & 1     & \red{n/a}     \\
          Multi-Grid    &  efu                  &  86.000               &      3.0 M           &   2.46 M            & 1     & \red{1137}    \\
          Multi-Blade   &  efu                  &  82.000               &      5.6 M           &   2.31 M            & 2     & \red{1494}    \\
          SoNDe         &  efu                  &  94.000               &      23.5 M          &  23.5  M            & 2     & \red{1307}    \\
    \Xhline{2\arrayrulewidth}
  \end{tabular}
\end{table}
  The large uncertainty for Gd-GEM comes from the fact that for this detector technology neutron
events gives rise to a range of readouts of up to 20 strip hits for both x- and y-
strips. \red{None of the readout systems supported Jumbo frames at the time of these experiments,
so the additional benefit of using large packets is not reflected in the reported rates.}

Taking into account that a \red{mid-range} server can have two CPU sockets, each having 8
cores/16 hyper threads we can naively scale these numbers to the very high event rates required at ESS
by parallelisation. For example, by employing a small number (5 - 10) of servers, each dedicated to
processing data from a fraction of the detector surface, we expect to scale the rates by more than an
order of magnitude.

\subsection{UDP Data Input}
\label{sec:udpperf}
At ESS we have chosen User Datagram Protocol (UDP) for the transmission of readout data
over Ethernet. Other contenders were Transmission Control Protocol (TCP), 'raw' Ethernet frames
and (briefly) InfiniBand.
UDP is a simple protocol for connectionless data transmission \cite{udp1} without a guaranteed delivery.
The alternative, TCP, guarantees the
ordered delivery of data and automatically adjusts transmission to match the capability of the transmission
link \cite{tcp1}.

Despite its inherent unreliability, UDP is widely used. For example in the RD51 Scalable Readout System \cite{srs}, or the
CMS trigger readout \cite{cms1}, both using 1 Gb/s Ethernet.
The ESS readout system described in section \ref{sec:readout} is based on FPGAs with support
for transmission of Ethernet packets over 100G. Implementing TCP on these are not
an option, so UDP was eventually decided.

The unreliability of UDP is widely overestimated. It is true that a UDP packet can
potentially be dropped in any part of the
communications chain: The sender, the receiver, intermediate systems such as routers, firewalls,
switches, load balancers, etc. This makes it difficult in the general case to rely on UDP
for high speed communications. However high reliability solutions can be engineered for simple network
topologies such as the one anticipated for the ESS readout shown in figure \ref{fig:ess_readout}.
This is a simple network topology, where both the FPGA and the switch can deliver packets at wire
rate. Thus no packet loss will occur except at the receiver.

At the receiver, two types of data loss are the main causes of performance degradation: buffer
exhaustion and packet processing overhead. These are not independent as increased time spent
in processing data will increase the likelihood that the receive buffers fill up.
Nevertheless the effects can be reduced as we describe in the following two sections.

\subsubsection{Receive buffers}
The main parameters for controlling socket buffers are \texttt{rmem\_max}
and \texttt{wmem\_max}. The former is the size of the UDP socket receive buffer, whereas the latter is the
size of the UDP socket transmit buffer. To change these values from a BSD socket application
use \texttt{setsockopt()}, for example

\begin{verbatim}
int buffer = 4000000;
setsockopt(s, SOL_SOCKET, SO_SNDBUF, buffer, sizeof(buffer));
setsockopt(s, SOL_SOCKET, SO_RCVBUF, buffer, sizeof(buffer));
\end{verbatim}

In addition there is an internal queue for packet reception whose size (in packets) is named
\texttt{netdev\_max\_backlog}, and a network interface parameter, \texttt{txqueuelen} which were
also adjusted for our benchmark testing.

The default value of these parameters on Linux are not optimised for high speed data links such as
10 Gb/s Ethernet, so for the measurements presented here the following parameters were used:

\begin{verbatim}
net.core.rmem_max=12582912
net.core.wmem_max=12582912
net.core.netdev_max_backlog=5000
txqueuelen 10000
\end{verbatim}

These values were generally adopted from previous studies \cite{bencivenni} and guides \cite{nwtune}.

\subsubsection{Packet sizes}
Packets arriving at a data acquisition system are subject to a nearly constant per-packet processing
overhead. This is due to interrupt handling, context switching, checksum validations and header
processing. There is an intimate relation between Ethernet link speed, packet size, packet rates and
header overhead as shown in table \ref{tab:i}. For 10G Ethernet at up to 15~M packets per second,
this processing alone can consume most of the available
CPU resources.

In order to achieve maximum performance, data from the electronics readout should
be bundled into jumbo frames if at all possible. Using the maximum Ethernet packet size of 9018~bytes
reduces the per-packet overhead by up to a factor of 100. This does, however, come at the cost of larger
latency. For example the transmission time of 64 bytes is 67~ns, whereas for 9018
it is 7230~ns. For applications sensitive to latency a tradeoff must be made between low packet
rates and low latency. For ESS latency is not an issue as all readout is time-stamped by
hardware before transmission.

By bundling readout data into Ethernet Jumbo frames of size 9018 bytes, rather than using
small Ethernet frames of size 64 bytes, the packet rate is reduced by a factor of 100 as shown in
table \ref{tab:i}. This is directly measurable as a reduced time spent in system calls and reduced number
of context switching between user space and kernel.

\begin{table}[tbp]
  \centering
  \caption{\label{tab:i} Packet rates as function of packet sizes for 10 Gb/s Ethernet}
  \smallskip
  \begin{tabular}{|l|cccccccc|}
    \hline
      User data size [B] & 1  &       18 &   82 &  210 &  466 &   978  & 1472 & 8972 \\
    \hline
      Packet size [B]    & 64 &       64 &  128 &  256 &  512 &  1024  & 1518 & 9018 \\
    \hline
      Overhead [\%]      & 98.8 &   78.6 & 44.6 & 23.9 & 12.4 &   5.5  &  4.3 &  0.7 \\
    \hline
      Frame rate [Mpps]  & 14.88 & 14.88 & 8.45 & 4.53 & 2.35 &  1.20  & 0.81 & 0.14 \\
    \hline
  \end{tabular}
\end{table}

We configured the systems with an MTU of 9000 bytes allowing user payloads up to 8972~bytes when
taking into account that IP and UDP headers are also transmitted. Given the efficiency gained by
using large packets, there was no need to consider InfiniBand or raw Ethernet
to reduce the size of protocol headers, thus confirming the choice of UDP.

\subsubsection{Performance}
For an early validation of the use of UDP we ran a series of performance tests using
an experimental configuration described in \red{appendix \ref{sec::testbed}.
The testbed} consists
of two hosts, one acting as a UDP data generator and the other as a UDP receiver. As mentioned
the readout transmitter at ESS will be based on FPGA and not a Linux server. However this
does not affect the results we measured for the receiver.

The measured performance, shown in figure \ref{fig:combined}, covers user data speed, packet error
ratios and CPU load. They are time averaged over 10 second intervals while transmitting 400~GB of
data at a time. There is a clear variation with packet size for all parameters with the
best results obtained with packet sizes larger than 2200 bytes. The best \red{results} in terms
of CPU bandwidth is obtained with a packet size of 9000 bytes.

\begin{figure}[tbp]
  \centering
  \includegraphics[width=0.65\textwidth,clip]{figures/combined.png}
  \caption{\label{fig:combined} Performance measurements. a) User data speed. b) Packet Error Ratio. c) CPU Load.
  Note that for the optimized values PER is zero for user data larger than or equal to 2200 bytes (solid line).}
\end{figure}

The tests made use of packet sequence numbers allowing the determination of packet error rates (PER).
Sequence numbers are not supported in the current prototype readout systems. Thus packet
loss and PER numbers are not available for these. Sequence numbers will, however, be part of the
ESS readout system.

The main conclusion is that with only a single cpu core used as the receiver it is possible to support
10Gbit/s with zero packet loss using UDP. The actual performance when real data is applied will
naturally change, and will need to be followed closely.

\subsection{Gd-GEM}
\label{sec:gdgem}
The NMX macromolecular diffraction instrument will use the Gd-GEM detector technology. The neutron converter is a \SI{25}{\micro\meter} thin
foil of gadolinium, which also serves as cathode in a gas volume ($\isotope{Ar}/\isotope{CO}_2$ 70/30 at athmospheric pressure).
After traversing the readout and the GEM foils, the neutron hits the converter where it is captured as shown in figure~\ref{fig:gdgem_detector}.
After the neutron capture, gamma particles and conversion electrons are released into the gas volume.

The conversion electrons loose energy by ionizing the gas atoms, and create secondary electrons along their path.
Due to an electric field, those secondary electrons are drifted away form the cathode to an amplification stage
consisting of a stack of two or three GEM foils. Each electron generates a measurable amount of charge by an avalanche
in the GEM holes, which induces a signal on a segmented anode.

This segmentation is realised by copper strips
with a pitch of \SI{400}{\micro\meter}. The signal on the strips is read out with a timing resolution in the
order of \SI{10}{\nano\second}, such that projections of the tracks in the x-t and y-t plane can be used to
combine hits in both planes (clustering) and reconstruct the neutron impact point (micro-TPC method)~\cite{gdgem2}.

\begin{figure}[tbp]
  \centering
  \includegraphics[width=0.6\textwidth,clip]{figures/scheme_3gem.pdf}
  \caption{\label{fig:gdgem_detector} Schematic drawing of the Gd-GEM detector in backwards mode. From \cite{gdgem1}.}
 \end{figure}

\subsubsection*{Readout}
The analogue signals of the strips of the Gd-GEM detector are read out by the VMM ASIC developed by Brookhaven National Laboratory for
the New Small Wheel Phase 1 upgrade \cite{vmm3}. The VMM has been implemented in the SRS~\cite{VMM_SRS} at CERN and a schematic
drawing of the readout chain is shown in figure~\ref{fig:gdgem_daq_figure}. The so called front-end hybrids are directly mounted onto
the detector. This PCB holds two VMM ASICs, each with 64 input channels connected to the anode strips with a spark
 protection circuit. For each hit strip where the signal surpasses a configurable threshold, the VMM outputs a 38
 bit binary word, see table~\ref{tab:vmm3}.

For the prototype a Spartan-6 FPGA on the hybrid controls the ASICs and bundles the data, that are transmitted via HDMI cables to the
core of SRS, the Front-End Concentrator (FEC) card. Up to eight hybrids can currently be connected to one FEC and the
data are encapsulated into UDP packages of a 1~Gb/s Ethernet connection to the readout computer \cite{gdgem_electronics}.

\begin{figure}[tbp]
  \centering
  \includegraphics[width=0.7\textwidth,clip]{figures/gdgem_daq_figure.png}
  \caption{\label{fig:gdgem_daq_figure} Figure of the Gd-GEM readout and data acquisition system, from \cite{VMM_SRS}.}
\end{figure}

The readout of the Gd-GEM detector is partitioned into 4 sectors. Each of these 4 sectors has 640 strips read out by
5 hybrids in x and y direction, resulting in a total of 5120 strips and 40 hybrids. If a signal is recorded on a
detector strip, the VMM on the hybird generates hit data for the corresponding channel. Before sending
out the data via UDP, the FEC adds the VMM ID and the FEC ID to the hit data.

\begin{table}
  \centering
  \caption{Data fields from VMM3.}\label{tab:vmm3}
  \smallskip
  \begin{tabular}{|l|r|l|r|l|r|}
    \hline
      \textbf{field} & \textbf{size (bits)} & \textbf{field} & \textbf{size (bits)} & \textbf{field} & \textbf{size (bits)} \\
    \hline
      flag & 1 & threshold & 1 &  channel & 6 \\
    \hline
      amplitude & 10 &  time & 8 &  BCID & 12 \\
    \hline
  \end{tabular}
\end{table}

With the information tuple (channel,  VMM ID, FEC ID), the geometrical position of each
hit can be reconstructed. A configuration file that reflects this digital geometry of the
detector is loaded during the start up phase of the DAQ.
The configuration can be modified for reordering, exchange or extension of physical readout components.

\subsubsection*{Processing requirements}
The Gd-GEM detector requires the most complicated processing requirements in
terms of the physical processes, the data acquisition and processing power.
  The steps required are
\begin{itemize}
  \itemsep0em
  \item parse the binary data from SRS readout and extract (time, channel, adc)-tuples
  \item queue up (time, channel, adc)-tuples until enough data for attempting clustering analysis
  \item perform clustering analysis - determine if coincidence occurred
  \item calculate neutron entry position for x and y
  \item convert positions to pixel{\_}id
\end{itemize}

Some of the software related challenges for Gd-GEM are: Scaling up to a full rate, detector size and
for discriminating invalid tracks. A neutron event generates a track with extensions in both time and
space so it is not possible to just partition the detector in regions for independent parallel
processing.
Several processing options for distinguishing which tracks from which position can be
extracted have been described in \cite{brightness1}. In addition, due to the required buffering of
data, memory usage and cache performance may well be a concern.

\subsection{Multi-Blade}
The Multi-Blade detector is a stack of Multi Wire Proportional Chambers operated
at atmospheric pressure, with a continuous gas flow. It consists
of a number of identical units, called cassettes. Each cassette holds a blade
(a substrate coated with $\isotope[10]{B}_4\isotope{C}$ ) and a two-dimensional readout system, which
consists of a plane of wires and a plane of strips. The cassettes
are arranged along a circle-arc centered on the sample, and are angled slightly
with respect to the neutron beam, for improved counting rate capability and spatial resolution.
The operation is based on the temporal and spatial coincidence of signals on strips and wires.
  Despite inherently being a three-dimensional detector, the visualisations of the detector images
typically display an ``unfolded'' two-dimensional pixel map. For further details of the design and
performance of this detector see \cite{multiblade2, multiblade4, multiblade5}.

\subsubsection*{Readout}
The Multi-Blade detector prototype currently has nine cassettes, each with 32 wires and 32 strips, for a
total of 576 channels. The readout is based on six CAEN V1740D digitisers, and a custom readout
application based on the API and software libraries supplied by CAEN. The digitisers each
have 64 channels, 32 for wires and 32 for strips. The wires and strips are connected to the
digitiser via front-end electronics boards. The final detector will have 32 wires and 64
strips per cassette, and up to 50 cassettes for a total of 4800 channels.

When the CAEN readout
system has detected signal above a certain (hardware) threshold it triggers an individual
readout of that channel. The readout consists of a channel number, a pulse integral (QDC),
a time-stamp, and digitiser id. For each trigger there will be one or more signals from both wires and strips.
The readout application continuously reads from the CAEN digitiser's hardware registers
using optical links and transmits the raw data over UDP to the event formation unit.

\subsubsection*{Processing requirements}
Readouts are subject to clustering analysis, where they are matched in both time and amplitude. The
maximum timespan for which channels can be said to belong
to the same cluster is a configurable parameter of the algorithm. For coincidence building
there can be up to 2 wires and
4 strips in a cluster, where the typical case is  one wire and two strips.
   Following clustering, we then calculate the pixel where the neutron was detected and
adds a timestamp. To summarise, the processing steps for Multi-Blade are:

\begin{itemize}
  \itemsep0em
  \item parse the UDP readout format to extract time, digitiser, channel and QDC values
  \item collect readouts in clusters
  \item map channel ids to either strips or wires
  \item check for coincidence (time and amplitude)
  \item combine wire{\_}id and strip{\_}id to pixel{\_}id
\end{itemize}

It is possible to improve the spatial resolution by employing CoG (center of gravity) on strip
readouts weighted by the deposited charge (QDC).

The measured amplitudes on the wires and on the strips are strongly correlated. This means that with
sufficient dynamic range double neutron events, which would cause some ambiguity, might be resolved
by requiring matching amplitudes \cite{multiblade2}.

  The processing pipeline for Multi-Blade currently differs from the other
detectors in that the code responsible for clustering and event formation runs in multiple
incarnations, namely one for each cassette. This is a case
where we explore the solution space for event processing. The approach has the advantage of supporting
individual processing for each blade rather than having to explicitly maintain information
about blade id's in the processing algorithm itself.

\subsection{Multi-Grid}
The Multi-Grid (MG) detector has been introduced at ILL and developed in a
collaboration between ILL, ESS and Link\"oping University. The detector is based on thin
converter films of boron-10 carbide \cite{hoglund, hoglundb} arranged in layers orthogonal to the incoming
neutrons.
  The MG detector uses a stack of grids with a number of wires running
through them.

Following the neutron conversion, a signals are induced both on grids
and wires, which are digitised and read out. The temporal and spatial
coincidence of the signals on wires
and grids is used to determine neutron positions. Signals can be induced on multiple
grids, and for double neutron events also on wires. The detector geometry
is three-dimensional, so our visualisation of the detector image consists of projections of
the neutron counts onto the xy-, xz-, and yz-planes respectively as shown in figure \ref{fig:multigrid_daq}.

\subsubsection*{Readout}
The Multi-Grid readout system used for prototyping and demonstration
detectors is based on stacked MMR readout boards supporting 128 channels,
a Mesytec VMMR-8/16 VME receiver card supporting up to 16 readout links, and a SIS3153 Ethernet
to VME interface card. It is self-triggered: when the Mesytec hardware registers a signal
above a certain trigger-threshold, it triggers a readout of all channels with signals above a
second threshold. This readout is
then transmitted as UDP packets to the EFU. The binary data format is hierarchical as it supports
multiple interface cards, each supporting multiple boards with up to 128 channels.

\subsubsection*{Processing requirements}
The Mesytec UDP protocol has been partially reverse-engineered based on captured network
traffic and the available documentation. The protocol parser must be able to support
multiple triggers in a single packet, and to discard unused or irrelevant data fields. The data fields
consist of 32 bit words each containing a command (8 bits), address/channel (12 bits) and ADC values (12 bits).
The channel readouts are given in alternating order (1, 0, 3, 2, 5, 4, ...).
All channels are assigned a single common 32-bit timestamp, in units of 16 MHz ticks, by the
electronics. Thus temporal clustering is performed in hardware, but no continuous global time
is currently available.

The EFU then parses the channel readouts, and applies software thresholds. At
this stage it discards inconsistent readouts. Channel readouts for Multi-Grid
are then mapped to either a grid or a wire id. The current algorithm for the Multi-Grid event
formation simply uses the maximum ADC values for grids and wires to determine the position. The
processing steps thus consist of

\begin{itemize}
  \itemsep0em
  \item parse the binary Mesytec readout format to extract time, channel and ADC
  \item discard inconsistent readouts
  \item map channel to either grids or wires
  \item apply suppression thresholds independently for wires and grids
  \item check for coincidence (must involve both one wire and one grid)
  \item combine wire{\_}id and grid{\_}id to pixel{\_}id
\end{itemize}

\begin{figure}[tbp]
  \centering
  \includegraphics[width=0.8\textwidth,clip]{figures/multigrid_daq.jpg}
  \caption{\label{fig:multigrid_daq} Grafana dashboard and live detector images from a
  recent test run with low neutron intensity at the Source Testing Facility at Lund University \cite{messi}.}
\end{figure}

\subsection{SoNDe}
\label{sec:sonde}
The Solid-state Neutron Detector (SoNDe) is based on a scintillating material that
converts thermal neutrons into light which is detected by a photomultiplier tube.
The detector is in an early stage of characterisation and is
currently available as a single module demonstrator \cite{sonde1}, shown in
figure \ref{fig:sonde_module}. It consists of a pixelated scintillator, a Hamamatsu H8500 series 8 x 8 MaPMT
 (Multi-anode Photomultiplier Tube) \cite{h8500pmt} and a SONDE/ROSMAP-MP counting chip-system to read out the MaPMT
signals \cite{rosmap}. The chip-system consists of four ASICs each responsible for readout of
16 pixels. The final detector will consist of 400 of such
modules, arranged in 100 groups of four modules in a 2 by 2 configuration. For a report on the
recent progress and patent information, see \cite{sonde2, sonde3}.

The ROSMAP
module transmits readout data in three different operation
modes as UDP data over Ethernet. The supported modes are Multi-Channel Pulse-Height Data,
Single-Channel Pulse-Height Data and Trigger Time Hits over threshold Data.
For early characterisation and verification it is necessary
to extract the charge information for individual channels and thus support for
the two ``expert mode'' data formats have been developed. When in operation at ESS only the
event-mode format (Trigger Time) will be relevant.

\subsubsection*{Processing requirements}
SoNDe belongs to a class of detectors requiring little data processing as the readout system
already provides event data in the form of (time, asic{\_}id and channel) values. The digital
geometry only has to account for the fact that two of the readout ASICs are rotated 180 degrees
compared with the others and the fact that they represent a view of the detector surface
from the back, which is different from the logical geometry definition we use.
  For the single module demonstrator, which consists of 8 x 8 pixels the processing steps are
\begin{itemize}
  \itemsep0em
  \item parse the binary readout data and extract (time, asic{\_}id, channel)
  \item combine asic{\_}id and channel to a pixel{\_}id
\end{itemize}

\begin{figure}[tbp]
  \centering
  \includegraphics[width=1.0\textwidth,clip]{figures/sonde_module.png}
  \caption{\label{fig:sonde_module} Single SoNDe module with PMT (left), ROSMAP module PMT interconnect side (middle),
  and digital electronics (right). Photos: European Spallation Source.}
\end{figure}

redpajama_set_name: RedPajamaArXiv


D and E will both feature books from John Buchan's Dickson McCunn series. I'm not going to apologise for this: I can think of few authors who are so good at landscapes, either real or imaginary, and, if you don't know the place yourself, it's difficult to tell where the seam is between the two.
D is for Dalquharter, but it's interesting to see how Dickson McCunn gets there. He starts in Glasgow – real enough – and takes a train.
Westward there ran out a peninsula in the shape of an isosceles triangle, of which his present high-road was the base. At a distance of a mile or so a railway ran parallel to the road, and he could see the smoke of a goods train waiting at a tiny station islanded in acres of bog. Thence the moor swept down to meadows and scattered copses, above which hung a thin haze of smoke which betokened a village. Beyond it were further woodlands, not firs but old shady trees, and as they narrowed to a point the gleam of two tiny estuaries appeared on either side. He could not see the final cape, but he saw the sea beyond it, flawed with catspaws, gold in the afternoon sun, and on it a small herring smack flapping listless sails.
The peninsula was called the Cruives – an old name apparently, for it was in antique lettering. He vaguely remembered that 'cruives' had something to do with fishing, doubtless in the two streams which flanked it. One he had already crossed, the Laver, a clear tumbling water springing from green hills; the other, the Garple, descended from the rougher mountains to the south. The hidden village bore the name of Dalquharter, and the uncouth syllables awoke some vague recollection in his mind.
By this point I'm very happily convinced. I've had my railway journey (and some extra trains), I have a reasonable idea how I'd get there from the real world, and I have been shown the map.
Dickson encounters a poet, John Heritage, who he's been avoiding, and they speculate about Dalquharter and Dickson's psyche before heading towards the village.
… There were not more than a dozen whitewashed houses, all set in little gardens of wallflower and daffodil and early fruit blossom. A triangle of green filled the intervening space, and in it stood an ancient wooden pump. There was no schoolhouse or kirk; not even a post-office – only a red box in a cottage side. Beyond rose the high wall and the dark trees of the demesne, and to the right up a by-road which clung to the park edge stood a two-storeyed building which bore the legend 'The Cruives Inn'.
Come to think of it, that's probably John Buchan's fault, too. More on that next time.
This entry was posted in reader's gazetteer and tagged books, john buchan, other people's books, the reader's gazetteer, travel. Bookmark the permalink.
Thanks for this post, I haven't read Huntingtower in DECADES! and I was wondering what to read next.


Stretchable and very comfortable in use. May be used as wil warbelt, as with trousers. Have new fast- type magnet buckle, which make opening process easier and faster. Suitable for daily life, tourism and airsoft.
Have four sizes: S – up to 90 cm (35 inches) ., M – up to 100 cm (39 inches)., L – up to 110 cm. (43 inches), XL – up to 120 сm. (48 inches).


text:
Q: Add/remove serilog logging level overrides at run time I am using Serilog in .Net 6 WebApi and the required serilog settings, including default logging level and few overrides, are currently being set via appsettings. However, I am looking for a way to dynamically add/remove logging level override for additional namespaces during runtime so that I can capture additional logs on demand for troubleshooting issues, without redeploying the application with setting changes. Is this possible? Any guidance available on how this can be achieved?
Thanks!

A: You can implement a custom configuration provider in .NET Core which reads the configuration from Database. And you may need to implement Reload option as well. So when you update the database - your configuration will get updated. Here are some references which may help you.

*

*Implement a custom configuration provider in .NET

*A Refreshable SQL Server Configuration Provider for .NET Core

*Creating a custom ConfigurationProvider for a Entity Framework Core source


text:
Jay Harrison Audio
Audio Producer, Sound Designer & Audio Research
Jay Harrison
The Sound Design of The Clangers: A Whistle-stop Tour
This week's post explores elements of the sound design in the iconic animated children's programme the Clangers. Originally produced between 1969 and 1972 by Oliver Postgate and Peter Firmin of British production company Smallfilms, the Clangers joined other Smallfilms classics Bagpus, Ivor the Engine & Noggin the Nog to create a highly distinguished body of work.
The video essay embedded in this post draws upon literature, interviews and archival footage to discuss the foundations of the sound design employed in the programme and goes on to explore how its characters were able to realise such a profound connection with their audience.
It considers the impact of the score composed by Vernon Elliott, the skilful narration provided by Postgate and presents an argument that the subtle production techniques underpinning the Clangers' distinctive whistled speech patterns are perhaps the most integral contributing factors to their enduring appeal.
The sources used in the production of the video are listed as follows:
- Embray, R., & Trunk, J. (2014). The Art of Smallfilms: The work of Oliver Postgate & Peter Firmin. London: Four Corners Books.
- Hayward, P. (2013). Whimsical Complexity: Music and Sound Design in The Clangers. In K, J, Donnelly (Ed.) & P, Hayward (Ed.), Music in Science Fiction Television: Tuned to the Future (pp. 72-86). New York: Routledge.
- Postgate, O. (2009). Seeing Things: A Memoir. Edinburgh: Canongate Books.
- Postgate, O. (Writer, Animator & Narrator), & Firmin, P. (Modelmaker & Illustrator). (1969). The Clangers: Flying [Television programme]. Canterbury: Smallfilms.
- Welch, F. [Director]. (2009). Oliver Postage: A Life in Small Films. [Television programme]. Bristol: Timewatch.
Machine Learning in Audio Production Podcast
The Compton Organ Company - Compton Electrone 357 - Part Three of Three
The Compton Organ Company - Electrostatic Generators - Part Two of Three


text:
To MIG or not to MIG, that is the question
By Stephen M. BirmanPartner
On March 26, 2013, a decision was rendered by the Financial Services Commission of Ontario in the case of Lenworth Scarlett and Belair Insurance Company Inc.
The applicant, Lenworth Scarlett, suffered soft tissue injuries, psychological injury and a TMJ injury arising from a motor vehicle accident which occurred on September 18, 2010.
The decision of Arbitrator John Wilson is the first decision regarding the Minor Injury Guideline ("MIG") pursuant to the MIG which came into effect on September 1, 2010 and which can limit the medical/rehabilitation benefits available to motor vehicle accident victims who have suffered a "minor injury" to $3,500.00. In a decision that will be very helpful to accident victims like Mr. Scarlett, Arbitrator Wilson found that the MIG did not apply in his circumstances.
Arbitrator Wilson noted that the default category of benefits under the SABS is non-catastrophic benefits (where $50,000.00 in medical/rehabilitation benefits are available). Arbitrator Wilson said that the MIG is a specified exception to non-catastrophic claims, that insurers should not rely upon where there is credible evidence of non-soft tissue injury, including psychological, emotional or cognitive impairment.
Arbitrator Wilson was critical of the insurer's "cookie-cutter" approach to relying on the expense limit under the MIG and commented that, "it makes no sense if the insurer is positioned to veto access to benefits on the basis of delivery of a single report, in the face of credible evidence to the contrary when the resulting delay in treatment could last for years." Arbitrator Wilson was also critical of the insurer having spent "a surprising" $3,658.60 on medical assessments (the insurer exceeded the MIG cap on assessments alone) to try and justify its MIG classification and only $1,582.34 on benefits.
Arbitrator Wilson held that because the applicant provided timely and credible information that taken by itself would have justified considering he was outside the MIG, the applicant should not have been considered to have suffered a minor injury.
Arbitrator Wilson's decision requires that insurers not make early claims decisions under the MIG, where there is any doubt whatsoever whether the MIG is applicable. The proper approach in these circumstances is to consider the reasonableness of the treatment, as it is proposed, as a non-catastrophic claim and not rely on the MIG claims limit.
This decision will hopefully end the practice of many insurers of automatically limiting claims to the monetary limits under the MIG where there are any signs of soft tissue injury, as the rigid approach is clearly unreasonable where there is credible evidence of a non-minor injury.
Most Recent News Stories
Riding Season is Open! Read this first
Canadian Class Action Commenced Against Breast Implant Manufacturer Allergan
Are you covered for an out of province motor vehicle accident?